A place users can post their projects. If you have a small project and would like your own dedicated place to post and have others chat about it then this is your spot.

User avatar
By Inq720
#94283 Like the second image "plant with water sensor server attached".

Jacob Major wrote:I did use the pictures you provided to realize I also needed to add guage.min.js so I grabbed that from the github you linked before. The gauge was a no show though. Probably becuase the following error.

" document.gauges.get("gauge-humid").value = v;" this line does produce an error
Cannot read property 'get' of undefined


A little web development understanding might help here. I think you mentioned your in CompSci, so I'm going to assume you understand Object Oriented Programming.
  • document is the web page object.
  • gauges is MykhaIloStadnyk's gauge array object. Can have multiple.
  • get is a function on his object to find one of the possible gauges.
The error message is saying that the gauges object is undefined (its not there) therefore it can't find the get function on it.

OK... I've set mine up to talk to the built-in AP like you have. Check that the gauge.min.js file is the same... 44763 bytes.
Files.png


I recall the file is already on your computer in the InqPortal library examples.
...\Arduino\libraries\InqPortal\examples\InqWeather\data\gauge.min.js

Hmmm... I just looked close and think you're using Chromium on an Raspberry Pi. Cool! 8-) I've not done any testing on that combination. Your a Beta Tester now! :D

If you have the F12 debugger open, set to the Sources tab and refresh the page. If it successfully finds and downloads the file, it will be in the left column list. Clicking on the gauge.min.js file will show you the contents.
gauge.png
You do not have the required permissions to view the files attached to this post.
Last edited by Inq720 on Thu Apr 14, 2022 11:09 am, edited 1 time in total.
User avatar
By Inq720
#94284
Jacob Major wrote:
Jacob Major wrote:Side note, in the original code you made, the percent of moisture was reversed so it was displaying 70% wet when it was 30% and vice versa. Obviously could change based on sensor type but just a note for anyone else.[/i]

Yes, that's the sensor. Apparently the light sensor (that I had laying around) works backwards. More light goes to zero, no light goes to 1024. But, good point for anyone else observing.
User avatar
By Inq720
#94285
Jacob Major wrote:Optimially since Moist is always between 0 and 100% I would like the graph to always have a scale of 0-100. Otherwise, the Graph has little in the way of context since it just occilates between a percentage like 50.23421324 and 50. 91232213 for a while. I need to be able to analyze the trend over a long period of time.


That is a perfectly understandable need. Unfortunately, InqHisto has to be able to generically plot any range... be it -0.05 to -0.01 or something like -1.6E6 to 3.7E10. It would be impossible in most cases for users to fix the ranges of every curve on the graph.

This has nothing to do with InqPortal and is highly customizing client code for a specific case. But, lets see if we can override the default behavior. You might have noticed in one of the previous posts, the debugger will show you the actual code. Here are the steps you'll need to do to achieve this goal.

  1. Refresh with the debugger open.
  2. Under the Sources tab
  3. Click on the InqHisto.js file.
  4. In the edit box, the source for InqHisto will show up. It is minimized which is basically compressed and takes all white space out. Its main purpose it to reduce the file size being sent to the browsers.
  5. Just to the bottom of the editor window, you'll see a pair of brace { }. Hovering over this will show you "Pretty print InqHisto.js"
  6. Clicking this reformats it.
  7. Copy and paste it to an editor and save it under a new name. Obviously with a js extension.
  8. In the index.html file, change the reference InqHisto.js to your new name.
  9. After editing both files, you'll upload them back to the server
  10. Refresh you browser and the new ones will load into the browser with the new feature.

Now as far as the modifications necessary to get a fixed range on the Y-axis, you'll need to consult the https://www.chartjs.org/. However, I've found Google search like "chart.js fixed bounds y-axis" might give you a better chance of finding the results you need.

If yours reformats InqHisto the same as my browser did, you should look at the code starting at about line 29
Code: Select all                    xAxes: [{
                        type: 'linear',
                        position: 'bottom',
                        scaleLabel: {
                            display: true
                        },
                        ticks: {
                            callback: (value)=>{
                                return Math.round((this.#_L - value) * 100) / 100;
                            }
                        },
                        afterBuildTicks: InqHisto.adjustTicks
                    }],
                    yAxes: []


The X axis is defined as there is only one.
The Y axis is not define and generated dynamically depending on how many curves are in it. The parameters that make up the X and Y axes is generic, so you will need to find how to fix the boundaries. You can dig around in this code to see where the X-axis is fixed as it is obviously fixed on the History tab. Try defining the X-axis in an analogous way.
User avatar
By Inq720
#94291
Jacob Major wrote:Additionally, I will need to be looking into a way to store the data locally on the server as a historical record. I was able to find a way to export the History Data but I would like to have it do that automatically at a set interval.
The goal of my project is a little unclear but I have free reign on how I would like to proceed. The two situations I was choosing between were:
  1. a set of sensors that would interface with a single device and upload all of their data to it at set intervals for a situation such as determining the soil levels of a large field. This could either be for a geology class at my university where the students need to repeatedly test soil over a large distance, or in an agricultural setting where a farm would place these sensors throughout the field and turn on watering (hoses?) as needed
  2. a personal plant monitor that can be modified to keep track of different plants with different watering needs and nutrient systems. Rather than being just automatic this also should have the ability to notify the user of the plant's status outside of the soft network created by the InqPortal.


OK... I think I understand your goal... having many such ESP8266 servers (INO Sketch w/ InqPortal built-in)... we'll call them Moisture Detection Servers (MDS). These MDS's on an interval upload data to another server say... a Raspberry Pi hosting Apache, Nginx and a MySQL database... we'll call it a database server (DBS).

At the moment, InqPortal does not have this ability. That is a more industrial type feature that I do have on my TODO list. My main focus up to now has been for student projects that stay visible only within their own home local area networks.

You're second point concerning the Soft network. It would be impossible to do what you want with the Soft AP network (regardless of InqPortal or any other web server). You need these multiple MDS to be able to talk to the DBS. The only way to do that is to connect to a common router using the LAN option (StationAP) that was discussed earlier. You would have to have your own local router (not the University's router). You would also connect your DBS to this router and the MDS's would then be able to talk to the DBS. (but again... InqPortal does not currently have this server to sever capability).

However it would be possible with what is currently available...
  1. Get a router so you can permit device to device communications.
  2. Setup all your MDS to connect to this router - Use the LAN connection setup in the Admin or hard-code it in the Sketch.
  3. Setup your DBS to connect to this router
  4. Instead of having each MDS actively submit its data to the server periodically (A PUSH process) you could create some kind of process on the RaspPi DBS to routinely poll each of the MDS servers (A PULL process) and gather their data and place it in the database... possibly using PHP, Python, or even C++, NodeJS. It could be kicked-off using a Linux daemon at an interval of your choice

This last item is beyond my knowledge base... This is a perfect example of asking others on this forum that have expertise in Linux daemons, and writing server scripts to access a web socket, gather data and push it to a DB.

OK... I think I have addressed all your problems and questions. Let me know if I missed one or are still having troubles with something.

VBR,
Inq