WH45 Sensor

[alexdelprete]

Hi,

first of all thanks for this addon, it's working fine with my Ecowitt system.

Today I received the new WH45 sensor and I installed it immediately. It measures PM2.5, PM10, CO2 concentration, Temperature and Humidity.

I was expecting it not being supported it and effectively, this is what I see in the log:

2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type tf_co2 value 56.8, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type humi_co2 value 72, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_co2 value 21.5, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_24h_co2 value 29.4, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_co2 value 24.7, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_24h_co2 value 29.9, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2 value 460, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_24h value 464, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_batt value 6, file a PR.
2021-02-02 18:58:28 WARNING (MainThread) [custom_components.ecowitt.sensor] Sensor pm25batt1 not in last update, check range or battery
2021-02-02 18:58:30 WARNING (MainThread) [homeassistant.config_entries] Config entry for shelly not ready yet. Retrying in 80 seconds
2021-02-02 18:58:30 WARNING (MainThread) [homeassistant.config_entries] Config entry for shelly not ready yet. Retrying in 80 seconds
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type tf_co2 value 56.8, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type humi_co2 value 73, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_co2 value 26.7, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_24h_co2 value 29.4, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_co2 value 28.4, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_24h_co2 value 29.9, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2 value 430, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_24h value 464, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_batt value 6, file a PR.
2021-02-02 18:59:29 WARNING (MainThread) [custom_components.ecowitt.sensor] Sensor pm25batt1 not in last update, check range or battery
2021-02-02 18:59:53 WARNING (MainThread) [homeassistant.config_entries] Config entry for shelly not ready yet. Retrying in 80 seconds
2021-02-02 18:59:53 WARNING (MainThread) [homeassistant.config_entries] Config entry for shelly not ready yet. Retrying in 80 seconds
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type tf_co2 value 56.7, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type humi_co2 value 72, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_co2 value 24.7, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm25_24h_co2 value 29.4, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_co2 value 24.7, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type pm10_24h_co2 value 29.9, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2 value 455, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_24h value 464, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt] Unhandled sensor type co2_batt value 6, file a PR.
2021-02-02 19:00:30 WARNING (MainThread) [custom_components.ecowitt.sensor] Sensor pm25batt1 not in last update, check range or battery

I hope it can be supported. Thanks a lot for your work on this.

Alessandro

[garbled1]

Oh man I need one of these. Let me look into what would be needed to support!

[garbled1]

Can I ask, what is "tf_co2"? Like co2 I'm guessing is ppm, pm10 and pm25 are reasonably obvious. I'm guessing humi_co2 is a humidity sensor?

[alexdelprete]

Can I ask, what is "tf_co2"? Like co2 I'm guessing is ppm, pm10 and pm25 are reasonably obvious. I'm guessing humi_co2 is a humidity sensor?

The WH45 provides 5 sensors: Temperature, Humidity, PM10, PM25, CO2.

From the product's page (https://www.ecowitt.com/shop/goodsDetail/98): "Measures indoor PM2.5, PM10, CO2 concentration, Temperature and Humidity every 60 seconds when powered with USB or detecting every 10 minutes when powered with batteries only."

Link to WH45 manual: https://osswww.ecowitt.net/uploads/20201225/WH45%20Manual.pdf

[alexdelprete]

I manually updated your modifications: as you can see from the screenshot below, most of the WH45 sensors are working, but I can't see the temperature (tf_co2) in the list, and the battery sensor is reported at the end of the list as unavailable.

Please note that the device is USB powered and has 2 backup batteries, I don't know what it reports when USB powered, I see from the logs I posted in my initial post a value of 6, and currently the device is powered via usb. I can try pulling the usb cable and see if it reports something different if you want.

If you want me to test something else please let me know.

[alexdelprete]

Ok, I can see some errors in HA log due to this in sensors.py:

# Battery value is 0-5 if self._dc == DEVICE_CLASS_BATTERY and self._uom == PERCENTAGE: return self._ws.last_values[self._key] * 20.0 return self._ws.last_values[self._key] _LOGGER.warning("Sensor %s not in last update, check range or battery",

the problem is that the WH45 reports a value of 6 when USB powered. That's why the sensor.wh45_battery is unavailable.

So one problem solved, now if I could only understand why the tf_co2 sensor is not shown in the list...:)

[garbled1]

Huh.. I guess the USB thing is odd and new.. I guess I'll have to compensate for that or just stick it to 100%, except, it should have presented as 120%... Unless HA marks 120% as unavailable because it's out of range?

The temperature one is more confusing to me. Is it showing up at all in the logs as being unhandled? Maybe delete the "tf_co2" entry from IGNORED_SENSORS at the bottom of const.py and see what that changes. If that changes things, I'll have to figure out an odd workaround.

[alexdelprete]

HA generates an error because it's out of the % range:

*Logger: homeassistant Source: custom_components/ecowitt/sensor.py:60 First occurred: 3:35:07 (1013 occurrences) Last logged: 14:29:18 Error doing job: Task exception was never retrieved Traceback (most recent call last): File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 283, in async_update_ha_state self._async_write_ha_state() File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 320, in _async_write_ha_state sstate = self.state File "/config/custom_components/ecowitt/sensor.py", line 60, in state return self._ws.last_values[self._key] 20.0 TypeError: can't multiply sequence by non-int of type 'float'**

I think they are providing 0-5 when on battery and probably 6 means "mains power (usb)". The strange thing is that I now disconnected the usb cable, and running on battery, but it still doesn't work. But I can't see what value it's sending. Is there a raw log somewhere I can check for values coming from the GW1000?

[alexdelprete]

I commented tf_co2 in const.py and disconnected the USB power cable, restarted HA and waited for data. Unfortunately the battery sensor status is still unknown and the temperature sensor is not shown in the list of entities:

[alexdelprete]

I can see this in the log now:

[garbled1]

There really isn't, unless you either hack the code to spit out what it's getting, or something similar. I think the trick I've used in the past was to use netcat to setup a listening port on the port # that the ecowitt is sending data to, and shutting HA down so I can hear it. That, or grab it with tcpdump with Ascii output.

OK.. The error for tf_co2 is odd, because the code in ecowitt is supposed to be converting that to a second value tf_co2c, for celcius, but obviously it isn't doing so, I wonder why... Maybe I should convert it to tc_co2 instead? (this is done in pyecowitt)

For the battery, hrmm.. I can fix that one, shouldn't be too hard... Just need to convert it to an int, not a float. Fun how every battery sensor is different on these things. :)

I really appreciate your help debugging this. It's somewhat hard to do without real hardware. Maybe I can fire up my test instance in the next few days and fake enough data to get it working...

[alexdelprete]

I thought there was a way to raise the debug level of logs for the single component to see the raw data coming on the tcp port. :)

Does pyecowitt actually support the WH45? Maybe it doesn't even know what tc_co2 is. From the raw value, it looks like tf_co2 is simply the F° value of the temperature. I thought your code simply took that value and converted it in C°. I still don't know how your component works, didn't have time to analyze it to help you nail the problem. My apologies.

Regarding the battery, now that I unplugged it, I was expecting the sensor showing the correct value, but it doesn't. So I think it's not as simple as we thought. The problem is that I can't see what values are coming through the tcp port. If usb power equals 6, I expect thatn when disconnecting the usb cable the usual 0-5 value is sent, but we need to verify this.

I know you don't have that sensor, that's why I'm trying to help the best I can. Whatever you need me to do, please tell me, am happy to help you fix this. Thanks for your work.

[garbled1]

pyecowitt should support this.. actually.. wait, that might explain the issue..

Did you also manually update pyecowitt? I haven't published a new version yet, so that would involve a manual replacement of the ecowitt.py code in the library folder from the github version. If you didn't do that, it might explain the temperature being missing, and the battery..

[alexdelprete]

I only updated the files of this specific project. So that's the issue. :)

How can I update pyecowitt manually?

If you want to move on more quickly, I'm available on telegram at @alexdelprete

[garbled1]

Find ecowitt.py in your python libraries directory... maybe just do a find for ecowitt.py. Replace it with this: https://github.com/garbled1/pyecowitt/blob/master/pyecowitt/ecowitt.py

I should have probably popped a new version of that, but I didn't have a chance to test it this weekend, so I didn't want to publish untested code. That being said, maybe make a backup of your original ecowitt.py somewhere.

[alexdelprete]

I had already searched for ecowitt.py file via HA's terminal, but didn't find one. Maybe it's in another container, but I don't know how to access it. Strange...

I also checked in /usr/lib/python3.8/site-packages, found nothing in there regarding pyecowitt.

[garbled1]

Ok, I'll try to update pyecowitt and do a basic test, and release 0.12 in the next day or so, then it should allow you to update.

[alexdelprete]

Ok, so I'll update through HACS and then test again. Thanks.

[garbled1]

OK, I updated pyecowitt to 0.12, and published that version. Would you mind manually updating the component to the latest git version and giving it one more go?

[alexdelprete]

So I reinstall it from HACS choosing "master"? Because I still see 0.5 as last version. I guess choosing master would pull the latest, right?

[alexdelprete]

Ok, I installed master, and restarted HA, here's the result. :)

Only issue I see is the 120%, that means the sensor is USB powered I guess. I'll try unpluggint the USB cable and see what happens...

[alexdelprete]

I unplugged the USB cable but it's not refreshing, I think the sensor has a 10min. cycle when on battery, so I need to wait and see what happens. The other strange thing is the temp/humidity reading, outside temp right now is 15.5°/43% humidity, and the WH45 is reporting 22.11°/32%. :)

[alexdelprete]

Ok, it just refreshed now, seems to be working fine, 40% battery, same value I see on WS View (2 bars).

The T&H values are completely wrong though...also on WS View, it's the sensor.

Integration seems to work fine now, you only have to show USB instead of 120% when the value is 6. Can you do it?

[alexdelprete]

Another thing I noticed: all sensors seem to be working ok now, except for Wind direction. I can't remember if it was working before...

[garbled1]

I don't have an easy way to fix the 120% -> USB thing.. because it's a numeric value... might have to live with it.. in theory you would only want to set an alarm if less than say 50% or something, so it should still be functional.

I'll double check on the wind side, make sure I didn't screw something up in the wind code.

[alexdelprete]

I understand what you're saying, it must remain a numeric value.

Can we do something like "if X>5 then X=5" so at least we see 100% and not 120%?

Another potential problem: in the list of sensors I see Outdoor Temperature but not Outdoor Humidity. Can you also check that one?

[alexdelprete]

Another suggestion, if I may: the sensors created don't have any reference in the name to your integration, and it's difficult to find the sensors when editing templates or automation stuff, in particular for people like me who have more than 1 weather stations, the sensors can overlap, or you can have difficulties distinguishing the same type of sensors coming from different integrations. Can you add a prefix to sensor names? something like sensor.ecowitt.indoor_humidity.

That would be great.

[alexdelprete]

I'll double check on the wind side, make sure I didn't screw something up in the wind code.

I noticed in the changelog that in last version you changed the code of wind direction. Maybe it's related to that.

While looking at the list of sensors, I found 3 of them with a red symbol in the end, that says "restored". Don't know what that means, but all 3 show as "unavailable" when you open them to check. Could be something old to delete?

[garbled1]

So yes and no. I've realized after this was kind of out in the wild, I probably should have done this. I even made an attempt to do so recently. The issue I had is that if I do, there wasn't an easy way to say "don't do that". People like me, that have grafana data for like a year going back, will be sad if all the sensor names suddenly change and the graphs are all messed up.

You can find the list of sensors through the device page, but yes, I realize it's still painful, because I too have a million sensors in my house. I'll look at what would be involved to fix again, see if I find another solution... or if anyone reading this wants to try to write one? :)

For the wind-dir, I think I see the problem... it's a metric/imperial issue. Lemme see if I can find a quick fix.

[alexdelprete]

Suggestion: an option to create sensors with prefix, and have it customizable. So for old users like you, no change, empty prefix, for new users like me, we input a prefix of our choice. The integrations can have options right?

I know where to find all sensors, but when you're editing config files with a text editor, it becomes difficult. That's why I still didn't create a panel for ecowitt yet.

[garbled1]

Yeah.. I might try to do that again.. it was my original idea, but I had trouble implementing...

I just pushed a new version to master that hopefully fixes the winddir, can you please test?

[alexdelprete]

sure...I'll reinstall. did you see the post about those 3 sensors with that red symbol?

[alexdelprete]

Working. But I don't understand: metric/imperial for direction, isn't it always degrees? :)

I still see those 2 unavailable sensors...are those coming from the GW1000? Can I disable them?

[garbled1]

Right, there is no metric/imperial for direction, but it was falling into the test for sensor name contains "wind", and then failing for being set to "not metric and not imperial". Good to see thats fixed.

Yes, the two batteries are probably from your GW1000. If they aren't being picked up anymore, you can delete.

I need to take a weekend and update HA to the latest version so I can test easier... I've been avoiding it due to the python nonsense. (I run a venv, because it's easier to code in)

That being said.. if everything is working for you now, I'll try and kick a new release out the door this weekend. The prefix name will have to wait, because thats more fiddly. Maybe capture your thoughts on that in a new issue so I don't forget about it..

[alexdelprete]

ok, thanks for your work. I'll open later another issue/request regarding the sensors' prefix. Hope it's not too hard to implement.

Good luck with the upgrade. I decided to go supervised exactly for this reason, got a 5y old NUC lying around, installed a 128Gb SSD in it and I installed HA on it. Works beautifully and upgrades are pretty easy now. Everything running smoothly.

If you need my help to test something, don't hesitate to contact me, @alexdelprete also on HA forum.

Thanks again.

Alessandro

[alexdelprete]

One thing: the WH40 is the rain sensor, I have it, I guess there's something wrong also on that, it should be the battery report I believe. And the WH25 is the WH32B (they renamed it), which is the T/H/B sensor for the HP2551. I have that too, I guess it's the battery report also on that one. So I won't delete them for now.

[alexdelprete]

Second thing: I mentioned in a previous post that Outdoor Humidity sensor is missing. Can you check it when you're at it? Thanks.

[garbled1]

Sorry, I can't find the humidity issue in the above.. can you re-explain that one? What sensor is missing? Just the std outdoor humidity

[alexdelprete]

For the Outdoor sensor (the one in the WS80) you should have Outdoor Temp and Outdoor Humidity, But in the list of sensors there's only Outdoor Temp.

I double-checked on WS View and ecowitt.net, and the values are both there, so the Outdoor T&H sensor is working.

Here you can see that for the Indoor sensor, you have both T&H, for Outdoor you only have the temp.

[garbled1]

OK.. Can you open a new issue for the WH80 humidity sensor? Are you getting any unknown or unhandled sensor alerts? I'd need to know what string the sensor sends for that...

[alexdelprete]

The WS80 is the station, that has several sensors integrated. I'll open a new issue with the relevant info.

[bromX]

Hi Guys,

I have a WH45 all linked to my ecowitt gateway. I installed the home assistant integration ('master' beta version) I am getting all of the normal sensor data but not the data from the WH45

In the logs I get

This error originated from a custom integration.

Logger: custom_components.ecowitt
Source: custom_components/ecowitt/__init__.py:262
Integration: Ecowitt Weather Station
First occurred: 11:11:43 AM (477 occurrences)
Last logged: 12:04:35 PM

Unhandled sensor type pm10_co2 value 2.1, file a PR.
Unhandled sensor type pm10_24h_co2 value 6.4, file a PR.
Unhandled sensor type co2 value 183, file a PR.
Unhandled sensor type co2_24h value 193, file a PR.
Unhandled sensor type co2_batt value 6, file a PR.

Do I need to download some additional files manually? I installed it all via HACS and then edited the manfest file and added in the version line.

Reading the thread above I am suspecting that I might need to upgrade pyecowitt but im not sure if I need to do some sort of manual process or if this is updated as part of the HACS install.

ps Great work on this integration!

Regards Ben

[alexdelprete]

Check this post (and the whole discussion): https://github.com/garbled1/homeassistant_ecowitt/issues/38#issuecomment-790706853

[zacs]

Regarding the 120%, the problem I've found is that other components rely on a 0-100 range. For example, in HomeKit, the 120% shows up as 20% (and thus is always in low battery state).

I imagine that just wrapping the battery value in min(value, 100) would solve the issue cleanly. I will give it a try if I have time in the next week.