You know… I don’t know how the library would respond to two gateways. This would be great to test!
The HASS UI might show some duplicate entity IDs, but the underlying unique IDs should be properly segregated (they include a unique identifier).
ecowitt2mqtt.Up for it?
Sure, I can give this a try.
Just to give you a little information on my setup, my GW2000 has my WS90 and lightning sensor, and my GW1000 and GW1100 have all my other sensors. The GW1100 is curently being used by the garbled1 integration, so I will try it with the GW1000.
I purposely blocked out all other sensors on the GW2000.
Alternativly, I could expose those sensors on the GW2000 and just use the one gateway…but that would be boring…
Just did it, shows up as two seperate devices reporting to HA!
5 minutes in, both devices are reporting normally.
HA adds “_2” to duplicate sensor names.
Excellent! I would expect the _2 suffix on duplicate entity IDs (since that’s what HASS does by default). Thanks for testing!
No problem at all it was simple enough to do.
This could be very useful for people who have more than one Gateway because they’ve exceeded their eight device limit per Channel, for example, soil moisture sensors temperature excetera.
@Anto79-ops’ and my discussion above made me realize something. Although Home Assistant MQTT Discovery users can quite easily point multiple gateways at a single ecowitt2mqtt instance, users of the “basic” mode (where the data payload is submitted to a single MQTT topic) can’t. That shouldn’t be the case: ecowitt2mqtt should support both use cases equally.
I’ve opened up a feature request to start noodling on it. I’m confident that most people here are HASS users (
), but if anyone isn’t and would like to weigh in (or if you’re a HASS user and would still like to weigh in), I’d welcome the conversation!
Interesting find! yeah, definitly I’m using this for HA.
If this makes any difference, I do have Ubuntu Server that is my MQTT broker (HA is not my broker) on the same network. I.e. the RPi that runs ecowitt2mqtt points to broker, and HA gets the broker information
In MQTT explorer, there are two different devices listed under homeassistant>sensors>device 1 (GW2000) and homeassistant>sensors>device 1 (GW1100), but not anywhere else.
Roger – that’s consistent with what I’d expect a HASS MQTT Discovery user to see. Your side of the house is looking good!
First of all, have been using the Addon for Home Assistant for a couple of days now and it just works!! So a big shout out and a thank you for developing.
I just have a question, I have the metric output - but wind speed is showing as km/h and not m/sec which I prefer. Would it be possible to have the weather station device be recognized as I weather station from He Assistant allowing us to use the new convention logic added in 2022.7 update?
Thanks!
Short Answer
Unfortunately, that is unlikely to happen. A quicker approach will be to define a template sensor that generates an m/s sensor – for example:
template:
- sensor:
- name: "Wind Speed (m/s)"
unit_of_measurement: "m/s"
state: >-
(states("sensor.original_sensor") | float × 1,000)/3,600
Long Answer
In the 2022.7.0 release blog post on this topic, a “weather services” link is referenced. As you would expect, this page shows all the integrations that are related to weather data in some way: Integrations - Home Assistant
Unfortunately, this blends a few concepts:
weather entity platform.The new 2022.7.0 functionality is geared towards #2; ecowitt2mqtt falls more in line with #1. I elected not to pursue #2 because ecowitt2mqtt contains data points that the weather platform doesn’t support; that would leave a weird scenario in which I have to implement both #1 and #2.
No criticism at all, but there are integrations that support both, eg weatherbit, openweathermap.
But I do appreciate it is much more work.
Good to know! Never say never.
Hi all! With the 2022.07.1 release, stations with a UV index sensor will start showing some additional goodies: how long various skin pigments (based on the Fitzpatrick Scale) can be in the sun unsunscreened before burning begins.
(I’m the author of the OpenUV HASS integration and got inspired by the fact its UV index is often different from a weather station’s because it (a) focuses on a broader geographical area and (b) doesn’t take things like cloud cover into account.)
Stay safe this summer!
<insert typical verbiage about how I am not a medical practitioner and this should not be construed as anything resembling medical advice>
Hi all,
I’ve completed the official ecowitt2mqtt Home Assistant OS add-on. I will ensure that this add-on always carries the latest ecowitt2mqtt version.
Many thanks to @smarthall for hosting one on my behalf!
To add the add-on to HASS OS:
I’ve tested everything on my end, and it appears to work correctly. Going to close this issue; for issues with the add-on, please use the https://github.com/bachya/home-assistant-addons repo.
I was looking through all the documentation, and I’m not seeing any way to have the MQTT notifications be retained in the broker. It’s not a big deal, but when I restart HA right now I have to wait up to a minute before any of the Ecowitt sensors have any data. If I’m understanding MQTT retention correctly, if the messages are marked to be retained, HA would get them at boot.
Or maybe I’m missing something?
You didn’t miss anything – I did! Thanks for the prompt. 2022.07.5 now offers support for this. Since it’s a “destructive” change (i.e., it alters the MQTT broker), it’s disabled by default if you’re using the Docker image or the PyPI package. Home Assistant OS users will have it enabled by default (since that’s the expected use case there).
I saw that pvizeli just introduced a PR to merge an Ecowitt integration into Core. How will that affect E2M?
They are separate projects, so it doesn’t affect it in any way. Both are great options. One plus for ecowitt2mqtt is that it offers many other calculated sensors.
Great to hear that it’s sticking around!
That reminds me I have a couple of calculated sensors that are in unavailable state - safe_exposure_skin_type_X, simmer_index, simmer_zone and windchill.
I went digging in the logs, I found entries that explained the simmer_index, simmer_zone and windchill, but the safe_exposure sensors didn’t log an error.
2022-08-29 15:59:11,269 | ecowitt2mqtt | DEBUG | Simmer Index is only valid for temperatures above 70°F (21.1 °C) (temperature: 51.62)
2022-08-29 15:59:11,270 | ecowitt2mqtt | DEBUG | Simmer Index is only valid for temperatures above 70°F (21.1 °C) (temperature: 51.62)
2022-08-29 15:59:11,270 | ecowitt2mqtt | DEBUG | Wind Chill Temperature is only defined for temperatures at or below 50 F and wind speeds above 3 mph. (temperature: 51.62, wind speed: 0.89)
I’m a real coding noob, so I wasn’t able to easily find out how the safe_exposure was calculated, but gathered it was based on the UV Index. Which for me is currently is 0. Is that assumption correct?
If you think it would be useful to help others understand why some of their sensors are in unavailable, I’d be happy to make a PR to add those situations to the Readme.
Or am I opening a can of worms, because there could be many other reasons why these sensors (and others) are unavailable?
You’re hitting in expected functionality: if there is no “real” value for a sensor because the underlying conditions don’t exist, the entity will get marked as unavailable.
That’s correct: when the UV index is 0, the safe expose calculation approaches infinity; since this isn’t a natural number, we mark the entity as unavailable.
I think that’s a great idea! You could probably get away with just adding a generic “some entities may become available; it’s because the underlying data is undefined” section to prevent having to list out every entity. At the same time, I should log a message (similar to windchill, simmer index, etc.) when this occurs for safe exposure times – that way, at least the logs are complete.