Atlas Scientific - EZO-HUM

[d.pancer]

I'm just jumping into Espeasy now. Quite a bit to take on and figure out. I already have a few DS18B20 hooked up to sonoff's working great.
I now want to include humidity. I'm interested in using the Atlas Scientific EZO-HUM sensor as it seems its the most waterproof humidity sensor out there (which is crucial for my project).

Is there any support for this? Can anyone help me out with this? I see for tasmota it has been accomplished already. I would prefer to stick with espeasy.

I'm also trying to figure out the following:

1. Can a DS18B20 and I2C device both be hooked up to a nodemcu?

[TD-er]

First a rather important warning, especially since you mention "waterproof".
Quite a lot of Sonoff devices do not have any isolation from mains power.
Especially the ones with power meter capabilities are connected to one of the mains power lines.

This makes them just dangerous to use with sensors connected to the internal electronics that can be reached from outside the enclosure.

So make sure to double check whether GND of the board is connected to any of the mains pins by using a multimeter (obviously while not having the unit plugged into mains)

Also when flashing such Sonoff devices (or any device that can be connected to mains) never have those connected to mains while connecting them to the computer.
You may seriously damage your computer and/or yourself.


About the Atlas sensor:
See the list of supported protocols: https://espeasy.readthedocs.io/en/lates ... al-plugins
P103 is about the Atlas Scientific EZO pH sensor, but I'm not sure if there is a lot of difference in their protocol for various sensors.



About your second question:
Yes, you can use both I2C and 1-Wire devices on a NodeMCU.
Just make sure both busses use separate pins. (1 for the 1-wire bus and 2 for the I2C bus)

[d.pancer]

Hey TD-er! thanks for the reply.

So now im a bit curious about the isolation you mentioned. Can explain how to check for isolation a bit more in detail? I'm using Sonoff TH16's for the sensor readings. But will also be using a Sonoff SV in the future. So your saying if there continuity between GND (on the sensor plug) and any of the mains (L / N / E) there is no isolation?





And yes! i'm fully away to flash only with 3.3-5v connected to the serial pins only while flashing.

I have come across P103 in my research here. So you're saying their protocol might not be so different from each other, but will that not effect how the data is read?

I have no idea how to build my own plugin for this. i'm going to continue learning and trying, but it would be amazing if someone who has knowledge on this can take the lead.

[Ath]

So now im a bit curious about the isolation you mentioned. Can explain how to check for isolation a bit more in detail? I'm using Sonoff TH16's for the sensor readings. But will also be using a Sonoff SV in the future. So your saying if there continuity between GND (on the sensor plug) and any of the mains (L / N / E) there is no isolation?

Correct, please re-read this:

Quite a lot of Sonoff devices do not have any isolation from mains power.
Especially the ones with power meter capabilities are connected to one of the mains power lines.

This makes them just dangerous to use with sensors connected to the internal electronics that can be reached from outside the enclosure.

So make sure to double check whether GND of the board is connected to any of the mains pins by using a multimeter (obviously while not having the unit plugged into mains)

------------------

I have no idea how to build my own plugin for this. i'm going to continue learning and trying, but it would be amazing if someone who has knowledge on this can take the lead.

This should best be coded as an addition to the existing code of P103, as that Humidity sensor is not yet supported by the plugin (AFAICS).

[TD-er]

These comment lines are from the plugin source code:

Code: Select all

// ###########################################################################
// ################## Plugin 103 : Atlas Scientific EZO pH ORP EC DO sensors #
// ###########################################################################

// datasheet at https://atlas-scientific.com/files/pH_EZO_Datasheet.pdf
// datasheet at https://atlas-scientific.com/files/ORP_EZO_Datasheet.pdf
// datasheet at https://atlas-scientific.com/files/EC_EZO_Datasheet.pdf
// datasheet at https://atlas-scientific.com/files/DO_EZO_Datasheet.pdf

So it already supports a number of other sensors from the same manufacturer.
This probably means we can easily adapt the plugin for the humidity sensor they make.
Some manufacturers use nearly the same protocol for all their sensors and you only need to use a slightly different formula to convert the raw values into the unit of measure you try to read.

The next logical step would be to compare datasheets of the already supported sensors to the EZO-HUM sensor you plan on using.


And yes, if there is any resistance between GND and either L or N of the mains connectors, then there is no isolation from mains.
And even if there is proper isolation, you still need to be careful.
For example what if you solder some wire to a GPIO pin and feed it outside of the enclosure.
If that wire internally comes close to a solder pad carrying mains voltage, the isolation of the cable you used may not be capable of withstanding several 100-s of Volt and thus create a spark and cause dangers to the users.

The Sonoff SV does seem to be a unit that doesn't have a mains input and thus is a much better choice for these use cases.

[d.pancer]

I was never able to get this working. My programing skills are too limited for this. Is there anyone out there that has the time and experience to take the lead on this.

Having a working system with a EZO-Hum on espeasy would be amazing.

[Ath]

If you have such sensor, and are available for testing, I can have a look at it.

I've worked on the code before (though only doing cleanup/minor improvements) and it looks rather doable to add the other available types of sensors (that are still available for purchase, as I'm not quite sure all still are, and I don't like to add any obsolete devices).

[d.pancer]

Yes! have two of these sensors hooked up to a Node MCU. I would REALLY appreciate the assistance with this! The EZO-Hum is still available and being sold and supported by atlas scientific.

I'll pm you in a day or two for some more details!

[Ath]

Yes! have two of these sensors hooked up to a Node MCU. I would REALLY appreciate the assistance with this! The EZO-Hum is still available and being sold and supported by atlas scientific.

I'll pm you in a day or two for some more details!

I've added a PR #4854 that adds (initial) support for the EZO HUM sensor, reading the Humidity, Temperature and Dew point (according to the documentation).
Downloads available form this GH Actions run (once that's finished). (You'll need to be logged in to your GH account to be able to download the binaries)

Feedback requested either in this thread or in the GH Pull Request.

[d.pancer]

This is amazing. Thanks for putting the time into this.
Looks like its going to take a while to compile. I'll start testing tomorrow and get back to you.

[d.pancer]

I'm working on this now. I have flashed the new build and have successfully added the sensor as a device. The device is, however, showing -1 readings for all channels.
I do have 4.7k resistors hooked up on both data pins.

https://ibb.co/5M44tct
Here the I2C address is found by espeasy

https://ibb.co/k2SLMdt
The config settings

When hitting submit on the settings an error message shows up:
https://ibb.co/ZgTL2bN

https://ibb.co/yRBr90r
here are the readings

[Ath]

Can you attach those screenshots in the message, (there is an Attachments tab below the edit field), instead of using an external service, as they tend to 'lose' the images in a couple of weeks/months, their pages are littered with ads, and the image is hardly visible because of size reduction that's applied.

[Ath]

Seeing the "brown out" message for restart, makes me wonder about the power supply to the EZO board.
Why it doesn't show any values is a bit strange, I'll log the read values at INFO level, so you can view it either from the Tools/Log page, or via an USB-Serial connection to the ESP.

I do recognize another error, overwriting the Voltage value, I'll fix that too.

[Ath]

I've updated the PR, a new build will be available from this GH Actions run in due time.

[d.pancer]

With this new build i'm able to see humidity readings being logged in the log under P103. So there is communication now!

The values column under devices still show -1 for all sensor readings.

In the device config window, hitting submit a few times give the same error:

Unable to send command to device WARNING : Board type should be 'pH', 'ORP', 'EC', 'DO', 'HUM', check your i2c address?

For the temperature and dew point reading a parameter setting/command needs to be sent. I have attached a page from the AS manual. Is this already implemented in the coding?

[Ath]

(Thanks for including the screenshots.)

Ah, I've now discovered some more errors that need fixing working on that.

From the EZO-HUM documentation you show, and that I've read already, I assumed that all values would be enabled by default, but obviously they aren't. I'm working on reading that Output parameter, and offer settings to enable Temperature and Dew point measurements. The Humidity reading will be enabled if it isn't yet, what else would you use this sensor for

The error message, shown after saving, is most likely caused by the sensor itself, as during the Submit action, the plugin is stopped, re-initialized and started again, to ensure all settings and initializations will be applied correctly. This part is by design. But what's not by design, is that these EZO boards can take up to 300 msec after applying a command, before a result is returned. That seems to be too long/slow for ESPEasy, so it may appear there is no sensor, but in fact it is just rather slow to respond, at times.
As we are kind of allergic to having delays in the ESPEasy code (this will block all processing on the unit ), I'm not sure if this is fixable, other than manually reloading the page.

[d.pancer]

Seems like you really know your stuff! Makes sense about that 300ms delay.

I tried going through the source code to find anything but its way above my level.
After not getting anywhere with espeasy I gave it a shot with Tasmota. They do have support for it, however, I also was not able to get any readings. Perhaps their code might help you out?

Here is a link for it.
https://github.com/arendst/Tasmota/blob ... ezohum.ino

[Ath]

Well, I have the Tasmota sources on my computer, 'for reference' the advantages of open-source software, and much more comfortable to navigate from VSCode

Their structure is very different from the ESPEasy structure, but the major difference is indeed that they seem to wait (using delay() calls) if the last command was sent 'too recent'. That won't work for us, as explained earlier. It's a subject that needs some more thinking though.

I've just pushed more changes, so the next build will be available from this GH Actions run in a short while.

[d.pancer]

Just flashed the latest. Unfortunately there is no observable difference from the last version. The values are still showing up as -1. Logging still does read the humidity values. Thought this would have been the one


Is there that much a difference between the other Atlus sensor to this one? I'm going to start going through the documentation of the other sensors and see if i can find anything that might help.

Grateful for the time you put in. Hope you can spare some more and get this to a working state.

[Ath]

Does it change if you enable the Temperature and Dew point options?, does it then f.e. show the Temperature value for Humidity?

[d.pancer]

Hold up, is'nt the temp and dew point options supposed to be enabled by the code?

I have never tried to issue a command via serial to the device. I assume this could be done through putty?

[Ath]

You should see those as EZO-HUM options in the Web UI now, (un)checked, depending on whether they are currently disabled or enabled, and when changing that, the sensor will be updated when the settings are saved.
If you don't see these options, then you don't have the latest update (or reading the values takes too long...)

[d.pancer]

I either missed those options (hard to believe) or somehow flashed the wrong version. I don't have the sensor with me now as I'm at work, but can run home and get it a bit later. I'll keep you updated.

[d.pancer]

you did it! The temp and humidity readings are now showing up as values! Awesome work!

Dew point and voltage readings are not showing up though. I believe the voltage reading can be removed completely from the values tab, however having it in there can be handy. As long as they show up

Turning the temp and dew point on via the web UI is a bit finicky. Once checked, it seems that after several Submits nothing happened. Sending the command together with the LED command seemed to turn them both off. I had to check both of them and hit submit several times to turn them back on.

Now i just noticed that after several submits, together with sending LED no/off command, i was able to get only dew point selected. With temperature values off, the dew point values do show up.

Even like this I can finally use this sensor! Thanks!!!!!!

[Ath]

Looking at the logs, maybe you can (also) spot a glaring bug in the firmware? The word 'Dew' isn't supposed to be included there...
I'll add a fix for that, and later also fix ignoring the Temperature value if it's not enabled (that'll be in the re-written plugin, see below)

For the general 'finicky' behaviour I'll have to rewrite the entire plugin, to make it work asynchronous, so a command can be sent to the sensor, and the required ~300msec later, the result can be read from the sensor. That should make it much more robust. In fact, I'm a bit surprised it actually works at the moment, as that required sync-delay isn't implemented anywhere
I'll work on that in parallel with some other ESPEasy projects (like I was already doing )

[Ath]

This GH Actions run should handle the unexpected 'Dew' inserted in the output, but you'll need to enable the Temperature to get both values. A proper fix will be included when I rewrite the plugin, as said earlier, couldn't include that in this quick fix.

[d.pancer]

Ahh good catch. Will test as soon as its done compiling and let you know.

so far this will get the job done for my application. I have it hooked in and sending data to my HA system already.

One observation is that every about minute all values default to -1.00. I'm assuming this is the equivalent of nan readings. It hangs for about 3 seconds and then the normal readings come back.
I was able to get around this by just including a rule to only send http commands if the values are > -1. I have had this issues with other sensors, but never found a concrete solution for it.


I'll keep an eye open for when you have the time to do a full re-write of the plugin.

[d.pancer]

This GH Actions run should handle the unexpected 'Dew' inserted in the output, but you'll need to enable the Temperature to get both values. A proper fix will be included when I rewrite the plugin, as said earlier, couldn't include that in this quick fix.

Dewpoint is now working. So all values except voltage are properly being displayed. The buttons work better than before but still a bit glitchy.

The log still shows "Dew" in it.

P103: READ result: 31.38,26.56,Dew,8.29

I guess we're good for now until the big re-write.

thanks again bro! really appreciate it.

[Ath]

One observation is that every about minute all values default to -1.00. I'm assuming this is the equivalent of nan readings. It hangs for about 3 seconds and then the normal readings come back.
I was able to get around this by just including a rule to only send http commands if the values are > -1. I have had this issues with other sensors, but never found a concrete solution for it.

If that is about other EZO sensors, then that is to be expected because of mentioned timing issues, as they all behave the same.
If that's about different sensors or ESPEasy in general, then maybe the MQTT Controller is periodically receiving a lot of (unneeded) traffic on the Subscribe topic(-group). If that's not really used, you'd better set it to something non-existing, or a very low-traffic topic, to avoid overwhelming ESPEasy with a lot of unused data.

Dewpoint is now working. So all values except voltage are properly being displayed. The buttons work better than before but still a bit glitchy.

That voltage is extracted from the Status command, similar to the voltage that is shown in the UI, but the commands are probably too close in succession to be handled properly, hence the need for the rewrite

The log still shows "Dew" in it.

Code: Select all

P103: READ result: 31.38,26.56,Dew,8.29

I guess we're good for now until the big re-write.

Yeah, I didn't try to manipulate the output, just check if the value is Dew and discard that to get the next. Hopefully it will be fixed in a future firmware update, though I don't know (yet) how to apply those...

thanks again bro! really appreciate it.

You're welcome

[d.pancer]

Hey Ath,

so everything is working great so far. All my sensor values are being read and with the rules to filter out the -1 values there is no issue.

Now a few days ago when i pulled up the device via browser i noticed all the formatting on the webpage is off. I just flashed the last version on a brand new Node MCU and im getting the same formatting issue. Any Ideas?

[TD-er]

Most builds do no longer have the CSS included in the build itself.
But those are being served from a CDN.
See: https://espeasy.readthedocs.io/en/lates ... Files.html

Maybe you can open the 'inspect' toolbar in your browser (right-click -> Inspect) and look at either the "Console" dialog, or the "Network" tab to see if you get a timeout or error for loading these files from the CDN servers.

Maybe those sites are being blocked by some firewall?
Or you don't have access to the internet while accessing the ESP?

[chromo23]

Probably this is connected to the issue i experiencing with jsdelivr...
I occurred also some days ago.

Bildschirmfoto 2023-11-10 um 10.27.52.png (198.53 KiB) Viewed 19352 times

Edit:

also the css can not be found here..

https://cdn.jsdelivr.net/gh/letscontrol ... lt.min.css

[TD-er]

Hmm apparently they now require the tag to be included.
Like this: https://cdn.jsdelivr.net/gh/letscontrol ... lt.min.css

[TD-er]

How is this build being made?
I think the build script really needs pygit2 to construct a valid CDN URL to be included in the build.
It takes the last tag to be included in the generated URL.

See "CDN_URL" in this debug code in the build output:

Code: Select all

 Compile time defines
 File System:      SPIFFS
 PROGNAME:         ESP_Easy_mega_20231110_minimal_core_302_ESP8266_1M_OTA_Domoticz_MQTT
 BOARD_NAME:       Espressif Generic ESP8266 ESPEasy 1M Flash 128k FS
 BUILD_PLATFORM:   Windows-10-10.0.22621-SP0
 GIT_HEAD:         feature/ESP32_IDF_5_1_f5d1baa
 CDN_URL:          https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy@mega-20231013/static/
 BUILD_VERSION:    20649
 BUILD_UNIXTIME:   1699606266
 BUILD_RFC1123:    Fri, 10 Nov 2023 08:51:06 GMT
 

[chromo23]

How is this build being made?

I don´t think it is about how the build is being made. If so this should have occurred long time ago...
Almost all my devices try to fetch from the same location as in the link i provided. It also failed suddenly

Some of my old devices get the files for colorcode still from my repository and there the "standard" link works fine...

https://cdn.jsdelivr.net/gh/chromoxdor/ ... ror.min.js

[TD-er]

Well I looked at the Python code used to generate compile-time defines and it defaults to the URL you gave when pygit2 isn't installed or is not able to find the last tag.

So I will change it into something like this for now till I get some idea to 'patch' this Python code

Code: Select all

def get_cdn_url_prefix():
    try:
        from pygit2 import Repository
        import re
        try:
            repo = Repository('.')
            try:
                # Test to see if the current checkout is a tag
                regex = re.compile('^refs/tags/mega-{0}'.format(repo.head.shorthand))
                tags = [r for r in repo.references if regex.match(r)]
                tag = tags[0]
                tag = tag.replace('refs/tags/','@')
                return "https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy{0}/static/".format(tag)
            except:
                # Not currently on a tag, thus use the last tag.
                regex = re.compile('^refs/tags/mega')
                tags = [r for r in repo.references if regex.match(r)]
                tags.sort()
                tags.reverse()
                tag = tags[0]
                # work-around to allow users to use files not yet available on a tagged version
                if '20220809' in tag:
                    return 'https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy/static/'
                    
                tag = tag.replace('refs/tags/','@')
                return "https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy{0}/static/".format(tag)
        except:
            return 'https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy@mega-20231013/static/'
    except ImportError:
        return 'https://cdn.jsdelivr.net/gh/letscontrolit/ESPEasy@mega-20231013/static/'

[d.pancer]

So does this need to be rebuilt in the custom build i received from @Ath?

[Ath]

We're working on a user-setting for the CDN host, but that's work in progress.

[d.pancer]

Any chance there is any workaround for the time being? I cant view logs remotely in this state and im trying to trouble shoot a connection problem to Influxdb. Can TD-er's suggestion be implemented for now?

[Ath]

Sorry, couldn't respond sooner, was at work and don't take my personal laptop there

You can always upload the .js and .css to the local filesystem, some instructions can be found here (1 file needs to be renamed before uploading, as written in that thread). Documentation on those files can be found here

Edit: Rename update_sensor_values_device_page.js to upd_values_device_page.js before uploading.
And just ignore the MACOSX folder, included in the zip, as it was created on a Mac.

Edit2: Added link to documentation for uploading the .js and .css files.

[d.pancer]

Thanks for response and detailed instructions.

After uploading the files The CCS formats are working, Saving rules is working, but the logging is still not working. Think ill just leave it at this for now until the issue is actually solved.

[Ath]

but the logging is still not working.

That's because the file "fetch_and_parse_log.js" is missing from the zip...

It can be downloaded from the repo

[chromo23]

That's because the file "fetch_and_parse_log.js" is missing from the zip...

ubbs... i´ll add it to the zip...

[d.pancer]

dam you're good! Worked like a charm. Up and running 100% now.

[d.pancer]

@Ath

Hope all is well!

I Need to update a few old devices. Any chance the last release has the new Atlus HUM code in it? Or should i keep on using that last build you created for me? Also has there been an updated on the CSS formatting "issue"? Going to read up on the latest release tomorrow, but as this update issue is urgent for my case im just trying to get a quick answer for now....thanks.

[Ath]

Hi, I've started an updated build for the PR in this Actions run, but I didn't get to the overhaul of the code yet. That's still planned, but other stuff got in the way