WXforum.net
Weather Station Hardware => Ambient Weather and Ecowitt and other Fine Offset clones => Topic started by: wx_junkie on March 11, 2021, 10:30:10 AM
-
Hi Gang,
I'm relatively quiet on this board, but I did feel compelled to share (with anyone interested) that the value of my Ecowitt System (GW1000 gateway + a whack of sensors....) took a massive leap forward in usefulness within the past few weeks. I wanted to take an opportunity to share my "discovery" with others, with the hopes it may precipitate (pun fully intended....) similar breakthroughs and/or usefulness.
For those of you who use or know about Home Assistant (the open source home automation platform), I was thrilled to find that someone had developed an integration for Ecowitt systems (https://github.com/garbled1/homeassistant_ecowitt (https://github.com/garbled1/homeassistant_ecowitt)).
(Incidentally, I'm actually curious whether the author (Garbled1 aka Tim Rightnour) is part of this board. If so, MASSIVE kudos go out to him. =D> )
Back to the task at hand.
Having integrated my Ecowitt and Home Assistant systems, has benefited me in 2 aspects:
1) New and useful (and customizable) ways to display the sensor data (example below). I must admit, I do like the look of the dashboard as provided by Ecowitt. No knocks against that whatsoever. But, now I can insert individual sensor data in other parts of my home automation / displays / dashboards. For instance, here is a dashboard that I have created for my vegetable garden, showing only those sensors that are important to me for gardening:
[ You are not allowed to view attachments ]
Don't pay too much attention to may garbled layout... I'm still experimenting with what types of gauges / sensor layout I prefer.
2) Ability to trigger home automation routines using Ecowitt sensor data. As an example, I am now triggering some lights to come on in the late-afternoon / early-evening, based on readings taken from the Solar Radiation sensor (as part of my WS68 Wireless Anemometer sensor). Conversely, I have lights turning off in the morning, once it is sufficiently light out. This is much more desirable than a time-based approach, as depending on cloud cover, I may want to delay turning off or on the lights. This is now fully automated:
[ You are not allowed to view attachments ]
I do have some more weather-condition-based automations in the queue. For example, I have a chicken coop door controlled by a microcontroller (also connected to Home Assistant) and linear actuator. It automatically opens each morning at sunrise. But, if it was pouring rain, for example, I may want to delay opening the door. To accomplish this, I could check the condition of the "rate of rainfall" sensor data as a condition, to ONLY open the door (after sunrise) once a rain-rate has fallen below a set threshold. I'm not sure I will actually do this exact automation, but it gives you a flavor of what types of things are possible. The sky is the limit, I expect.
Again, just wanted to share in this experience and "plant the seed", as the saying goes. I'd be happy to hear from anyone who has also mated these 2 systems together - I welcome you to share some of your automations and dashboards!!
Regards,
Ray
-
I like the compost temperature!
Now need to dig into Home Assistant
-
Hi Gang,
I'm relatively quiet on this board, but I did feel compelled to share (with anyone interested) that the value of my Ecowitt System (GW1000 gateway + a whack of sensors....) took a massive leap forward in usefulness within the past few weeks. I wanted to take an opportunity to share my "discovery" with others, with the hopes it may precipitate (pun fully intended....) similar breakthroughs and/or usefulness.
For those of you who use or know about Home Assistant (the open source home automation platform), I was thrilled to find that someone had developed an integration for Ecowitt systems (https://github.com/garbled1/homeassistant_ecowitt (https://github.com/garbled1/homeassistant_ecowitt)).
(Incidentally, I'm actually curious whether the author (Garbled1 aka Tim Rightnour) is part of this board. If so, MASSIVE kudos go out to him. =D> )
Back to the task at hand.
Having integrated my Ecowitt and Home Assistant systems, has benefited me in 2 aspects:
1) New and useful (and customizable) ways to display the sensor data (example below). I must admit, I do like the look of the dashboard as provided by Ecowitt. No knocks against that whatsoever. But, now I can insert individual sensor data in other parts of my home automation / displays / dashboards. For instance, here is a dashboard that I have created for my vegetable garden, showing only those sensors that are important to me for gardening:
[ You are not allowed to view attachments ]
Don't pay too much attention to may garbled layout... I'm still experimenting with what types of gauges / sensor layout I prefer.
2) Ability to trigger home automation routines using Ecowitt sensor data. As an example, I am now triggering some lights to come on in the late-afternoon / early-evening, based on readings taken from the Solar Radiation sensor (as part of my WS68 Wireless Anemometer sensor). Conversely, I have lights turning off in the morning, once it is sufficiently light out. This is much more desirable than a time-based approach, as depending on cloud cover, I may want to delay turning off or on the lights. This is now fully automated:
[ You are not allowed to view attachments ]
I do have some more weather-condition-based automations in the queue. For example, I have a chicken coop door controlled by a microcontroller (also connected to Home Assistant) and linear actuator. It automatically opens each morning at sunrise. But, if it was pouring rain, for example, I may want to delay opening the door. To accomplish this, I could check the condition of the "rate of rainfall" sensor data as a condition, to ONLY open the door (after sunrise) once a rain-rate has fallen below a set threshold. I'm not sure I will actually do this exact automation, but it gives you a flavor of what types of things are possible. The sky is the limit, I expect.
Again, just wanted to share in this experience and "plant the seed", as the saying goes. I'd be happy to hear from anyone who has also mated these 2 systems together - I welcome you to share some of your automations and dashboards!!
Regards,
Ray
Hi - I just got my weather station and am trying to set up that integration too, in HA. Did you have issues getting the sensors to show up in HA? I can't seem to get it connected correctly. Any help you could provide would be great.
-
Use this one instead https://github.com/PoppyPop/homeassistant_ecowitt
But don't follow the instructions to installl as that will add the repository from "garbled1", who does not seem to work on the project anymore.
Instead download the files and add them to HACS manually.
-
After I saw this post, I searched for Ecowitt from Homebridge.
There’s a plug-in!!!
Set it up and I see some data points in HomeKit …. But needs further configuration or setup.
-
Use this one instead https://github.com/PoppyPop/homeassistant_ecowitt
But don't follow the instructions to installl as that will add the repository from "garbled1", who does not seem to work on the project anymore.
Instead download the files and add them to HACS manually.
Good to know. I did manage to get the garbled1 version installed, but it did require some manual editing of some of the files. I wonder what the best way to name the sensors/entities that are getting pulled in? Can I hard-code the names in my GW-1100 that will then get pulled into HA?
-
Hello,
I just setup the GW1004 gateway in Home Assistant. Some file Configuration had to be done. It wasn't too bad had to read posts in issues tab to figure a few things out. I have been using a SDR_RTL dongle to bring in my Ecowitt products data into Home Assistant. I am going to continue to use the Dongle because I have many mixed frequency sensors. I use the wind speed from my Atlas to shut the awning if wind speed is high. I also use many moisture sensors in garden to push stats to a package in Home Assistant that calculates rainfall, temp, pressure, soil humidity and etc to adjust the watering time. I have only scratched the surface of the possibilities of what Home Assistant and RF products can do.
"Good to know. I did manage to get the garbled1 version installed, but it did require some manual editing of some of the files. I wonder what the best way to name the sensors/entities that are getting pulled in? Can I hard-code the names in my GW-1100 that will then get pulled into HA?"
The sensors are auto named but can be easily changed in Home Assistant to your naming configuration.
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
Hi,
Just got a fresh new RPi 4 4GB and would like to install Home Assistant (HA) OS on it to veiw my Ecowitt sensors (and possibly do other stuff with it). It seems I have the option of installing a 32 or 64 bit version of HA. Could anyone tell me which OS bit version I should install if I want to use the Ecowitt plugin?
I saw this video, which is good, but it doesn't address which bit version I can use.
https://www.youtube.com/watch?v=wNe5DxvOAoM
Also, would this work with GW1100?
thanks
-
I believe that the 32 vs 64 bit difference is simply due to what hardware you're running. The integrations / add-ons should work regardless. I have mine running an a pi4 with an SSD.
-
Use the 64bit version of HA
Yes the GW1100 should work just fine.
I am just experimenting with HA myself
-
great, thanks good to know.
Being a 4Gb you can do either the 64 or 32bit, while the 8GB supposedly requires the 64bit and the 2 Gb only 32bit is recommended.
I was reading some posts (which are likely outdated now) that the 64bit HA had a rocky start, but now is fine.
Ok, 64-bit it is. thanks.
-
I don't know what your experience level is with this kind of stuff, but i started out using an sd card. I moved over to an SSD recently and the performance gains are worth the effort, imo.
I'm curious to see what kind of automations you guys come up with! I have some basic stuff like notifying when it's raining at home, and high wind alerts that tell me to close the garage (but only if it's open at the time). I also picked up some soil sensors and the PM meter, etc. I haven't figured out anything clever to use them for yet, though.
-
I highly recommend using one of the remote backup options for Home Assistant. There are add-ons for samba, Google Drive, etc.
-
I don't know what your experience level is with this kind of stuff, but i started out using an sd card. I moved over to an SSD recently and the performance gains are worth the effort, imo.
I'm curious to see what kind of automations you guys come up with! I have some basic stuff like notifying when it's raining at home, and high wind alerts that tell me to close the garage (but only if it's open at the time). I also picked up some soil sensors and the PM meter, etc. I haven't figured out anything clever to use them for yet, though.
Am still experimenting on a Pi2 and SD card, but quite impressed so far.
I will likely migrate to a Pi4 and SSD in the near future.
Not sure that I will use anything weatherwise for triggers in my smart home but just like the idea of it being all capatured etc
-
Got this running on my RPi 4B via HAOS and its reporting numbers on the HA dashboard. Nice!
So, I also have another datalogging system on my network where I have a Ubuntu machine (server) that has InfluxDB and Grafana.
Anybody know how I can get HA with Ecowitt plug-in to send the data to my Ubuntu server InfluxDB? Do I have to configure NodeRed on the HAOS?
I guess im not certain how the Ecowitt plug-in sends the data out.
thanks
-
I believe that there is an add-on or integration for InfluxDB and Grafana that may be helpful, though I've not used it so can't provide more info than that, sorry! I use Node Red to set up automations, but I don't think it's required to push data to InfluxDB. There's some HA forums and an HA discord channel you can use for more direct support.
-
No devices or entities.
I've installed the poppy fork but with no luck at getting devices or entities to appear. I've had the GW1000 working on another app, so I'm familiar with the setup. Startup in the log appears normal. Any ideas?
[ You are not allowed to view attachments ]
-
I managed to get this work on HA with dataloging via InfluxDB to Grafana (on another server in home). I also got it work with Google Assistant, most of sensors are now able to be voice commanded to that. For example, Hey Google, what is front tree soil moisture humidity? and it tells me the number...it doesn;t display it on the Nest Hub....im working on that.
It was pretty straightforward.
Did you add HACS to HA? After that, you should be able to add the Ecowitt Weather Plugin, from which you will have to set up the plug to get it speak to HA. After restart, you see the entites box in for Ecowitt and it reports your sensors
-
Yes, I Downloaded the poppy version through HACS. Originally I tried the garbled1 version. The integration is installed, but it doesn't populate with my devices. Looking at the manifest I do have the poppy version installed.
-
Hmm, ok I have the garbled1 installed on HA OS running on RPi4. Maybe try the garbled1 again...im not sure what then problem could be without log files.
-
Log file shows the integration starting without an error. Does your log show ecowitt devices? Mine doesn't
-
It show the entities available when I go to the integration page. The only issues I have in the log is that the plug-in doesn't support my leaf wetness sensor. (yet)...are you entities showing up on the integration page? like this below? if so, just click on entities and you should see the individual entites/sensors
[ You are not allowed to view attachments ]
-
I have no devices or entities created by the integration.
-
I would recommed uninstalling the plug-in, restarting, and try again. It seems its not configured properly.
Also, confirm that the GW1100 is broadcasting data.
-
I don't know if this will made a difference, maybe try putting this in te path in your WS View app ( and restart HA and the Ecowitt GW1000).
/data/report/
-
Log file shows the integration starting without an error. Does your log show ecowitt devices? Mine doesn't
You need to have a / in the path on WS-VIEW. It doesn't matter what is in that line as long as it is terminated with a "/"
-
Goooooooooal! I have a device and entities. Thanks.
Since I using the new app, and it shows the / on the page, I assumed it was included. Apparently not. Thanks.
I originally set up my GW1000 on the new Ecowitt iOS app. WS View only shows the mac of my GW1000. I didn't want to delete the pairings and start over.
Apparently the newer app works fine for setting the GW1000
-
Hey if you are using PoppyPop's updated fork through HACS, for some reason mine did not install the latest. I had to manually copy over the latest from git in custom components/ecowitt for it to see my soil temp.
-
At the moment, I currently have my GW1100 integrated to HA via garbled1. It works pretty well, minus some log errors for unhandled sensors.
I'd now like to add a second device (while keeping my first device, GW1100, also connected). Do I simply add it via the custom server integration in the WS app (like how the GW1100 was setup)? Will HA recognize it as a a new, second device?
The second device I'd like to add is the GW2000.
Cheers
-
just wanted to bump this again, the Wittboy box says its "Home Assistant Ready", so, has anybody been able to get the Wittboy to report to Home Assistant, yet?
At the moment, I currently have my GW1100 integrated to HA via garbled1. It works pretty well, minus some log errors for unhandled sensors.
I'd now like to add a second device (while keeping my first device, GW1100, also connected). Do I simply add it via the custom server integration in the WS app (like how the GW1100 was setup)? Will HA recognize it as a a new, second device?
The second device I'd like to add is the GW2000.
Cheers
-
What's a good solution for checking Ecowit availability in Home Assistant? My GW1000 seems to be reconnected to wifi every 3-6 months. Thanks.
-
just wanted to bump this again, the Wittboy box says its "Home Assistant Ready", so, has anybody been able to get the Wittboy to report to Home Assistant, yet?
At the moment, I currently have my GW1100 integrated to HA via garbled1. It works pretty well, minus some log errors for unhandled sensors.
I'd now like to add a second device (while keeping my first device, GW1100, also connected). Do I simply add it via the custom server integration in the WS app (like how the GW1100 was setup)? Will HA recognize it as a a new, second device?
The second device I'd like to add is the GW2000.
Cheers
Apologies for delays.
I believe that you just need to add a second instance of the Integration into HA running on a different port and it will take the data from the GW2000
I am not sure why Ecowitt are saying Home assistant compatible unless they are writing an integration themselves! The custom integration I am currently importing data from my GW2000 does not understand the Wittboy or any of the newer sensors yet
-
thanks @Mandrake for the reply.
Indeed you are correct. If I want more than 1 Ecowitt device reporting, I would have to use a different port.
I have not added the GW2000 to HA yet, for that reason that its not supported yet. Following the Github, it seems the have a semi-wroking PR for the Wittboy
https://github.com/garbled1/homeassistant_ecowitt/pulls
Does anyone know if this integration/script is maintained? It works well and super stable with my GW1100, with the exception of the unhandled sensors, and lightning sensor confirguration which floods my logs, it really just needs some tweaks.
-
yep, thats the custom integration I am using with my GW2000.
No issues other than the unsupported sensors which flood the logs
I am not sure how well its maintained as I have logged problems and not seen any response and there has no updates in a while
-
do we just need to update const.py with the missing sensor consts and type defs? It's currently over my head.
edit: yes.
If you just want to stop the logs from filling up, you can add your unknown sensor type to /ecowitt/const.py IGNORED_SENSORS = [] group after you define it.
my failing unknown type was [runtime].
# added to type definitions section in const.py:
TYPE_RUNTIME = "runtime"
#added to IGNORED_SENSORS = [] group:
"runtime",
#example:
# "dewpoint8f",
# "runtime",
# DATA_PASSKEY,
-
I was able to set up runtime as a sensor and a template sensor for parsing the seconds.
# added to type definitions section in \config\custom_components\ecowitt\const.py:
TYPE_RUNTIME = "runtime"
# added to SENSOR_TYPES = section in \config\custom_components\ecowitt\const.py
#
# Name, unit_of_measure, type, device_class, icon, metric=1, state_class
#
TYPE_RUNTIME: (
"Runtime",
None,
TYPE_SENSOR,
None,
"mdi:run-fast",
0,
None,
),
#
#
This will get you a sensor.runtime with a running seconds total from the device's start.
To see it parsed in weeks, days, hours, minutes, and seconds you can use a template sensor.
template:
- sensor:
- name: "Ecowitt Uptime Long"
state: >-
{%- set uptime = states.sensor.runtime.state | round -%}
{%- set sep = ', ' -%}
{%- set TIME_MAP = {
'week': (uptime / 604800) % 604800,
'day': (uptime / 86400) % 7,
'hour': (uptime / 3600) % 24,
'minute': (uptime / 60) % 60,
'second': (uptime % 60)
}
-%}
{%- for unit, duration in TIME_MAP.items() if duration >= 1 -%}
{%- if not loop.first -%}
{{ sep }}
{%- endif -%}
{{ (duration | string).split('.')[0] }} {{ unit }}
{%- if duration >= 2 -%}
s
{%- endif -%}
{%- endfor -%}
{%- if uptime < 1 -%}
just now
{%- endif -%}
-
in other news, one of the big boy devs at HomeAssistant is moving to wittboy. https://twitter.com/pvizeli/status/1538869201288499200
-
thanks @Mandrake for the reply.
Indeed you are correct. If I want more than 1 Ecowitt device reporting, I would have to use a different port.
I have not added the GW2000 to HA yet, for that reason that it's not supported yet. Following the Github, it seems the have a semi-working PR for the Wittboy
https://github.com/garbled1/homeassistant_ecowitt/pulls
Does anyone know if this integration/script is maintained? It works well and super stable with my GW1100, with the exception of the unhandled sensors, and lightning sensor configuration which floods my logs, it really just needs some tweaks.
He mentions in the 2021 issues log, that he expected the integration to make it to the HA core in 2022.3. Unfortunately, that did not happen. Here's to hoping that it makes it and Ecowitt partners with them to ensure it's updated before firmware hits the street.
-
He mentions in the 2021 issues log, that he expected the integration to make it to the HA core in 2022.3. Unfortunately, that did not happen. Here's to hoping that it makes it and Ecowitt partners with them to ensure it's updated before firmware hits the street.
Any idea where we can lend support to having Ecowitt as a core integration? That would be amazing!
-
I found another Ecowitt/HA intergration. I installed it on another raspberry pi that is bring in my water and gas meter reading to HA via MQTT
Took me 5 minutes to get one running with my GW2000.
https://github.com/bachya/ecowitt2mqtt
-
Hi!
another Ecowitt/HA intergration
If MQTT is sufficient to connect HA, this could also be solved via FOSHKplugin that may already exist anyway.
This could then also pass the metric values to HA if required.
Is MQTT sufficient or does native HA integration offer significant advantages?
Oliver
-
MQTT is absolutely sufficient for HA. The conveience of course is having one system do everything, as opposed to having another system doing the work, and dumping the output to another platform like HA. HA has auto discovery and this particular integration supports HA output format (by including the "--hass-discovery" option when starting the program, otherwise its your standard topic/name format.
Also include this option "--output-unit-system metric" will send metric values to HA.
I just got it to run as a service on my Raspberry Pi and it handles the Wittboy with no problems at all! I really like the garbled1 also, but I'm starting not like all the error messages in my logs for unhandled sensors. Plus, the person who has developed this mqtt-based code, is super responsive to your issues.
If FOSHKplugin has MQTT output option, then yes, this could be a good way (and very common way) to get it into HA
-
Hi!
If FOSHKplugin has MQTT output option, then yes, this could be a good way (and very common way) to get it into HA
FOSHKplugin has also a MQTT output option (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#MQTT).
All sensors are supported, additional values are calculated (min/max, cloud height, sun hours, dew point, ...) and status messages (battery alarm, thunderstorm alarm, storm alarm, ...) are also output via MQTT.
It would be nice if an HA user could test and confirm this. I do not use HA here myself.
Oliver
-
Hi Oliver,
It sounds like FOSHKplugin has everything we need!
I was just reading how to install FOSHKplugin and looks like I need a dedicated RPi to run Loxberry, is this correct?
If so, I won't have an option now to test it as I don't have an extra RPi laying around. I would really like to try this so, once some RPi come in stock at my supplier, I can give it a go!
Can I install this on a Windows computer?
-
Hi!
I was just reading how to install FOSHKplugin and looks like I need a dedicated RPi to run Loxberry, is this correct?
No, you don't need a separate LoxBerry nor a LoxBerry installation at all.
The generic version of FOSHKplugin is able to run as a (parallel) service on any 24/7 Linux computer which may already serve other things.
The installation process (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#Installation) is quite simple.
On Windows it only runs within a WSL (Windows Subsystem for Linux) - so it needs a Linux as the base.
Oliver
-
I found another Ecowitt/HA intergration. I installed it on another raspberry pi that is bring in my water and gas meter reading to HA via MQTT
Took me 5 minutes to get one running with my GW2000.
https://github.com/bachya/ecowitt2mqtt
Does this one create a device with the entities grouped under it? Are there data that ecowitt creates from the raw sensor values that wouldn't be captured by the MQTT output? Versus the reading from the weather station hardware? Like, does the console/Gateway crunch data then creates a new data point that is not output by the weather station hardware? Hopefully that makes sense.
-
yes, it creates one device (GW2000 for example) with all the entities below it, for example here is mine:
[ You are not allowed to view attachments ]
According to the documentation, you can have raw data also if you use the "--raw-data" config keyword. see this:
https://github.com/bachya/ecowitt2mqtt#raw-data
I presonally use the crunched data because I have some offsets in GW2000.
By the way, if you are using metric, include the meteric keyword before you feed it to HA because i oringally had imperial and then switched to metric and HA complained later that the entities had wrong units, so include this "--output-unit-system metric"
-
You're right, that is simple enough to install, the instructions are there line-by-line.
Ok, im going to see if I have enough overhead on the same pi that im already running two mqtt services and try it out.
Hi!
I was just reading how to install FOSHKplugin and looks like I need a dedicated RPi to run Loxberry, is this correct?
No, you don't need a separate LoxBerry nor a LoxBerry installation at all.
The generic version of FOSHKplugin is able to run as a (parallel) service on any 24/7 Linux computer which may already serve other things.
The installation process (https://loxwiki.atlassian.net/wiki/spaces/LOXBERRY/pages/1252524456/FOSHKplugin+-+generic+version#Installation) is quite simple.
On Windows it only runs within a WSL (Windows Subsystem for Linux) - so it needs a Linux as the base.
Oliver
-
a dockerized version of FOSHKPlugin as an HomeAssistant addon would be awesome.
-
Ecowitt is now an official integration as of 2022.9
https://next.home-assistant.io/integrations/ecowitt/
-
YES! That's so exciting.
-
I need to convert this weekend! heck yea!
being a n00b, proper steps to remove the HACS integration with the HA core integration?
1. delete the integration
2. remove the repository from HACS (probably optional)
3. install integration from core
4. re-setup ecowitt device with new port(if applicable)
5. fix cards with new object names (if applicable)
6. profit $$$?
-
Please let me know how it works!
I'm using bachya's ecowitt2mqtt on a separate raspberry pi and sends my data via mqtt. I'm very happy with this (it works well and its on a separate RPi so I can easily set it to update every 16 seconds or less without worrying too much about CPU overhead), so, I'm curious how the official add-on works in HA.
-
I'll do it since I am only using the data on the page, not triggering or automating anything with the data.
-
I need to convert this weekend! heck yea!
being a n00b, proper steps to remove the HACS integration with the HA core integration?
1. delete the integration
2. remove the repository from HACS (probably optional)
3. install integration from core
4. re-setup ecowitt device with new port(if applicable)
5. fix cards with new object names (if applicable)
6. profit $$$?
Any thoughts about migrating the historical data over, if that's even possible?
-
I have it running now. it is nice and clean, but [runtime] data is not being pulled from the stream =(. As soon as the dust settles, I'll see if we can request that to be added since I like knowing if the device has restarted itself.
-
Awesome good to hear.
Of course one of the advantages of it being an official integration is that it will constantly be improved and request like this I'm sure can be easily accommodated.
-
I need to convert this weekend! heck yea!
being a n00b, proper steps to remove the HACS integration with the HA core integration?
1. delete the integration
2. remove the repository from HACS (probably optional)
3. install integration from core
4. re-setup ecowitt device with new port(if applicable)
5. fix cards with new object names (if applicable)
6. profit $$$?
These are the exact steps I took.
I did remove the repository from HACS, and
#4 was a little more change on ws_view than on HA.
#5, the integration uses FIRMWARE_NAME as the entity prefix, so mine is ex sensor.gw1000b_v1_7_5_absolute_pressure
-
Wait... Firmware name?
So when you update FW it will change the name and thus your automation?
Hope not!
-
Wait... Firmware name?
So when you update FW it will change the name and thus your automation?
Hope not!
I hope not as well, but we'll have to wait for the next firmware update to test =).
-
will see how the EW HA integration behaves with a change of console device firmware ...
might just continue, only as a new device, but history might get lost respectively not remain in one piece when the old devices are still kept
EW might better use the device name visible in WS View Plus e.g. GW2000A-WIFIxxxx and distinguish some console types by the last four characters of the device MAC address
-
#5, the integration uses FIRMWARE_NAME as the entity prefix, so mine is ex sensor.gw1000b_v1_7_5_absolute_pressure
the device name is built by the scheme console-typeFrequency_Vfirmware; e.g. GW1000B_V1.7.5 and the sensors correspondingly
[ You are not allowed to view attachments ]
[ You are not allowed to view attachments ]
-
... it is just the stationtype (key in Ecowitt format) ...
Oliver
-
... it is just the stationtype (key in Ecowitt format) ...
Oliver
yes, sure - but inside HA the dependency of the (HA) device on the firmware version is imo not really desirable.
-
He'll fix it if it becomes the issue we think it will. I *think* he just got started with Ecowitt with the Kickstarter, so he probably hasn't been through a firmware update yet.
-
He'll fix it if it becomes the issue we think it will. I *think* he just got started with Ecowitt with the Kickstarter, so he probably hasn't been through a firmware update yet.
He = ?
-
yeah, most devs at Home Assistant are awesome and responsive. I've worked with more than a few on troubleshooting stuff and in the end, it gets fixed or works.
For the ecowitt integration, its Pascal Vizeli, he'll be the guy that will fix any issue with this.
https://github.com/pvizeli
-
I have flagged to the Dev responsible that the integration is still missing leaf wetness sensor.
He said he will look at this next week.
Its also been flagged on the ticket about the naming so hopefully that will get looked at as well.
-
He'll fix it if it becomes the issue we think it will. I *think* he just got started with Ecowitt with the Kickstarter, so he probably hasn't been through a firmware update yet.
It's not only a potential issue when a firmware upgrade happens.
It's already an issue when you connect more than one console of the same model and firmware now.
Difficult to impossible to tell which one is which .... as they have the same device entry.
(or can you rename the devices ? provide an alias or so ? Didn't find an option to do so)
By chance, accidentially I can tell one from the other when clicking on the device as the WS90 firmwares have a different version - but what if not .....
-
I have flagged to the Dev responsible that the integration is still missing leaf wetness sensor.
He said he will look at this next week.
Its also been flagged on the ticket about the naming so hopefully that will get looked at as well.
Can you ask about parsing the runtime data from the stream? I was able to add it with garbled1 here: https://www.wxforum.net/index.php?topic=41676.msg448140#msg448140
if not, I'd really appreciate knowing the appropriate spot for feature requests, if you have it.
Thanks!
-
I will ask if we can add the uptime as a value from the data stream.
Can someone else try and see if the integration allows them to dump a diagnostic for them. For me it fails every time.
-
fails for me as well. I think the url is crafted wrong or the file is missing.
I submitted an issue for this behavior: https://github.com/home-assistant/core/issues/78190
-
I note that the diagnostics upload was fixed in 10.9.2 as I was able to upload the diagnostics.
I am told by the Dev that the missing entities (in my case leaf wetness) will be included in the next release (2022.9.5)
-
Anyone try the GW1000 1.7.6 update yet ?
-
Anyone try the GW1000 1.7.6 update yet ?
I will try around 18:00HRS EST today, when I get home =)
Edit: All upgraded and not seeing any glaring issues on this unit, I will hold off for a few on the others. I've learned to wait with ecowitt a few days on ones I do not like having issues.
-
Anyone try the GW1000 1.7.6 update yet ?
I will try around 18:00HRS EST today, when I get home =)
Edit: All upgraded and not seeing any glaring issues on this unit, I will hold off for a few on the others. I've learned to wait with ecowitt a few days on ones I do not like having issues.
Did your entities change in home assistant with the new firmware version number?
When I upgraded from HACs integration to official integration; my entities were e.g.: sensor.gw1000b_v1_7_5_absolute_pressure
I changed them all to e.g:
sensor.absolute_pressure
So that my cards and automations wouldn't need changing.
Did your entities change from sensor.gw1000b_v1_7_5_absolute_pressure
To sensor.gw1000b_v1_7_6_absolute_pressure or were the entities left as you had them ?
-
I forgot to mention that. The entity_id stayed the same, the name changed to
name: GW1000B_V1.7.6 Battery 1
entity_id: binary_sensor.gw1000b_v1_7_5_battery_1
-
Just updated GW1000. The Home Assistant entity ids and entity names stayed the same for me. No renaming names or entity_ids needed [tup]
-
For Your Information:
Updating Home Assistant (HA) to core version 2023.5 via WebUI gives a setup problem of the HACS integration Ecowitt in HA :-x . Ecowitt therefore does not "load" in HA.
Via the WebUI I downloaded the full Log with error messages and went back to the previous version via the official HA Add-on "Terminal SSH" with the command:
ha core update --version 2023.4.6
Terminal SSH page stucks on "processing". After a while I had a look via the App on my Smartphone to HA and the version 2023.4.6 was reported so fallback works, HACS integration Ecowitt works Oke, as all my other HA stuff too.
"Terminal SSH" does "hang" on "processing" and at the end I pushed the button "Exit Page" on "Page Unresponsive" message and then got the message on via WebUI that all went Oke with the fallback to 2023.4.6 (see picture).
According to the log it seems there are problems with the RAIN-rate figures.
Tomorrow I will see where to report the issue with Ecowitt in HACS with the log with errors attached.
[ You are not allowed to view attachments ]
-
Extra info for my previous post with error on Ecowitt in Home Assistant.
I have a Ecowitt Gateway (Version: GW2000A_V2.2.3) connected via a ethernet-cable to my HA.
-
The "Ecowitt HACS integration" problem with HA core 23.5 is reported as an issue on Github. I added my LOG etc. tot this issue. see: https://github.com/home-assistant/core/issues/92496
-
Hi,
I am about to buy https://www.froggit.de/product_info.php?info=p515_dp2000-7-in-1-ultra-wifi-lan-gateway-wetterstation.html&no_boost=1
which includes gateaway, and my question is if it is needed if I will be integrating it into home assistant? Can DP2000 communicate directly with HA (which is installed on RPI4).
Thank you.
-
All Ecowitt (clone) consoles can post their data via the so-called "Customized" option.
The HA Ecowitt Integration uses this functionality.
So, yes, the GW2000/Froggit DP2000 can send its data to HomeAssistant.
(I have it successfully installed myself in a HA Docker container, BTW)
-
Hi,
I am about to buy https://www.froggit.de/product_info.php?info=p515_dp2000-7-in-1-ultra-wifi-lan-gateway-wetterstation.html&no_boost=1
which includes gateaway, and my question is if it is needed if I will be integrating it into home assistant? Can DP2000 communicate directly with HA (which is installed on RPI4).
Thank you.
Thanks Gyvate for answering the question.
To complete: the HACS integration in Home Assistant (HA) is not supported anymore and does not work as from HA version 23.5. There is now an official HA integration which works fine with Ecowitt and others
-
correct, the Ecowitt integration for/of/from the HomeAssistant Community Store (HACS) solution no longer seems to work.
I'm running HA 2023.7.2 and there is an official Ecowitt integration available ....
it's a bit tricky for a newcomer to distinguis between HA, HACS, hassio, hass.io, HassOS .... and the different implementation methods and their feauters/limitations .... :roll:
EDIT: too many typos #-o
-
Hello all,
I had a working Ha integration with HA version 2023.07 via the ECOWITT integration. With my gateway version (GW2000A_V2.2.3).
But suddenly I could not get any data into HA. I tried to reinstall GW2000 (now version 3.0.5), but no entities were displayed in HA. After updating HA to version 2023.08.01, no entities were displayed either. I have reset the gateway but after all attempts I have not got any further. I am able to access the web interface and enter the configuration for the HA, but no entities are displayed in HA. I have to enter the IP address of the HA in GW2000 and also the Internet URL (with which it worked before). I have tried with and without the slash in front of the API. Is there a protocol I could use to see the error? Does anyone have a tip for me.
-
did you re-install the Ecowitt integration ? (maybe not necessary)
did you re-install the device (GW2000) ? (maybe necessary)
did you note down/save the (probably new) Webhook provided by HA for the device ?
As you appear to be German: (or is this Hamburg, NY)
the entries needed in the Customized section of the GW2000 for HA (except for your specific webhook ;)), if the HA instructions appear to be a bit scarce, can also be found in
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen#custom_server
I suggest your read the whole section (better even the whole WiKi 8-)).
There you also find how you can chek your custom server postings via a server provided by one of our contributors.
But I don't think it's a GW2000 issue. I just connected, for fun and testing purposes, a GW2000 to my HA (2023.7.2) and it works without issue.
-
Hello all,
I had a working Ha integration with HA version 2023.07 via the ECOWITT integration. With my gateway version (GW2000A_V2.2.3).
But suddenly I could not get any data into HA. I tried to reinstall GW2000 (now version 3.0.5), but no entities were displayed in HA. After updating HA to version 2023.08.01, no entities were displayed either. I have reset the gateway but after all attempts I have not got any further. I am able to access the web interface and enter the configuration for the HA, but no entities are displayed in HA. I have to enter the IP address of the HA in GW2000 and also the Internet URL (with which it worked before). I have tried with and without the slash in front of the API. Is there a protocol I could use to see the error? Does anyone have a tip for me.
It is very likely the webhook. There have been other people who have missed that step because its a change from the older HACS integrations
-
It is very likely the webhook. There have been other people who have missed that step because its a change from the older HACS integrations
Is it possible to find this URL with the webhook (/api/webhook/xxxxxxxxxxxxxxxxxxxx) which is shown in a window at device creation (and which I luckily copied) somewhere (except maybe in your WSView/WebUI in the Customized setup) in HA ??
I tried to figure that out (the xxxxxxxxxxxxxxxxxxxxxxxxxxxx), but at no avail, no click would work - or maybe I was blind ...
Or is it shown only once during creation and then no more ? And then, if you lose it, you need to delete the device and create it again newly ?
-
did you re-install the Ecowitt integration ? (maybe not necessary)
did you re-install the device (GW2000) ? (maybe necessary)
did you note down/save the (probably new) Webhook provided by HA for the device ?
As you appear to be German: (or is this Hamburg, NY)
the entries needed in the Customized section of the GW2000 for HA (except for your specific webhook ;)), if the HA instructions appear to be a bit scarce, can also be found in
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen#custom_server
I suggest your read the whole section (better even the whole WiKi 8-)).
There you also find how you can chek your custom server postings via a server provided by one of our contributors.
But I don't think it's a GW2000 issue. I just connected, for fun and testing purposes, a GW2000 to my HA (2023.7.2) and it works without issue.
Thanks for the Informations @Gyvate, i am from Germany, right.
: did you re-install the Ecowitt integration ? (maybe not necessary)
Yes i did 20 times
: did you re-install the device (GW2000) ? (maybe necessary)
Yes i did also
: did you note down/save the (probably new) Webhook provided by HA for the device ?
Yes , when i reinstaleld the integration HA automatic created a new api webhook
: As you appear to be German: (or is this Hamburg, NY)
Germany
:the entries needed in the Customized section of the GW2000 for HA (except for your specific webhook ;)), if the HA instructions appear to be a bit scarce, can also be found in
https://www.wetterstationsforum.info/wiki/doku.php?id=wiki:wetterstationen:ecowitt-stationen#custom_server
i will read it
:I suggest your read the whole section (better even the whole WiKi 8-)).
I will do first
I am just not sure to use the slash in the GW2000 in front of the path ? i tried it with and without.
-> I didn't used a HACS before, i just started with the HA Integration in 2023-07
My Problem is , in 2023-07 the Integration worked already and suddenly it was disconnected. thats when the story started ...
rgs
-
you may wish to consider using Bachya's (also an HA dev) Ecwott2mqtt as an addon in HA OR on a separate RPi via mqtt. I've been running this for over a year now on another RPi4, and been as stable as a rock.
https://github.com/bachya/ecowitt2mqtt
Bachya is a awesome and responsive developer. Any issues are resolved in days.
-
I am just not sure to use the slash in the GW2000 in front of the path ? i tried it with and without.
the slash definitely has to be there - otherwise HA will not find the data resp. the posting string will be malformed
the firmware puts http:// in from of the string and concatenates the other entries:
from the below entries the posting string will be http://192.168.1.200:8123/api/webhook/xxxxxxxxxx
if you omit the slash, it will become http://192.168.1.200:8123api/webhook/xxxxxxxxxx which is not a valid URL
(of course the IP address is from my system ;))
this is also mentioned in the WiKi I pointed you too 8-)
leading and trailing blanks (spaces) in the field(s) may also be an issue
-
Wittboy and HA reveiw
https://www.youtube.com/watch?v=lz2TipTphbc
-
Does anyone else have a GW2000/GW1000 with a WN34L temp sensor ?
The native HA integration picks up the WN34L as a CH1 soil sensor, and then creates a static battery voltage sensor (which just shows 2.06V)
Live data from the GW2000 shows that the battery is reported as '5' (and it labels the sensor as CH1), which seems to correlate with the 1-5 battery scale that some other Ecowitt sensors use...
-
Does anyone else have a GW2000/GW1000 with a WN34L temp sensor ?
yes
The native HA integration picks up the WN34L as a CH1 soil sensor, and then creates a static battery voltage sensor (which just shows 2.06V)
and ... ?
Live data from the GW2000 shows that the battery is reported as '5' (and it labels the sensor as CH1), which seems to correlate with the 1-5 battery scale that some other Ecowitt sensors use...
where and how do you get "5" as live data for the WN34 battery status ?
And what's exactly your question here ?
-
You can get a live data response by typing in
http://ip.of.your.gw2000/get_livedata_info?
The issue/question is that HA is incorrectly reporting my WN34L as a WN34C (I think those are the correct models - so C is soil ?)
And as such is giving me a battery voltage sensor, and that is never updated. It appears to be that based on the live data page, the WN34 actually reports a 1-5 scale for battery, rather than an actual voltage.
So I was wondering if those with the same hardware combo had similar issues in HA
-
Hi!
And as such is giving me a battery voltage sensor, and that is never updated.
Even though different sensors in the Ecowitt format actually provide the battery values in volts, there is apparently a specification for standardisation within the JSON query, in which the battery values are output exclusively as a scale in the value range from 1..5.
This means that the real overview is lost. However, there is no need for special treatment of the various sensors and the same processing method can be used for all battery values.
I find the lack of separation of numerical values and the unit in the JSON much worse!
Oliver
-
1. How is HA reporting your WN34L as a WH34C ?
your entity name should be something like gw2000X_v.3.0.7_soil_temperature_channel-nr_battery
So where in HA is your WN34 reported as WN34C ?
In which country are you located ?
2. the GW2000 is oblivious of the difference in WH34L or WH34S - it only knows a user temp sensor channel 1-8 - the WN34 series.
3. when you have set up your GW2000 in HA, you should know where it gets its data from - from the customized console posting and not from a livedata http call - these are two different "protocols".
You want to see how that protocol looks like ?
Connect your console (GW2000) temporarily to http://ear.phantasoft.de - first connect via browser and read the instructions
Contrary to the http call, the custom server posting uses the live data as is - the same way as the local Ecowitt Gateway API provides it - there comes the voltage from.
4. what batteries are you using ?
-
1. How is HA reporting your WN34L as a WH34C ?
your entity name should be something like gw2000X_v.3.0.7_soil_temperature_channel-nr_battery
So where in HA is your WN34 reported as WN34C ?
Sorry, I meant that if it was generating an entity with the name soil temperature, it was confusing it with a WN34S (soil). Yes, the entity names are sensor.gw200c_soil_temperature_1 etc
In which country are you located ?
Australia
2. the GW2000 is oblivious of the difference in WH34L or WH34S - it only knows a user temp sensor channel 1-8 - the WN34 series.
3. when you have set up your GW2000 in HA, you should know where it gets its data from - from the customized console posting and not from a livedata http call - these are two different "protocols".
Contrary to the http call, the custom server posting uses the live data as is - the same way as the local Ecowitt Gateway API provides it - there comes the voltage from.
4. what batteries are you using ?
Ah ok - I assumed the http call to the gateway would be the same as the API.
I'm using Energizer AA batteries. Old or fresh batteries, the voltage in HA shows 2.05V, and does not seem to be updated (other than when I reload the integration or have changed the actual batteries)
How often is the battery voltage updated for your WN34 sensors in HA ?
-
Have you read our MUST READ thread (which has got its name for valid reasons 8-)): https://www.wxforum.net/index.php?topic=40730.0 ?
then you would know where the C for WN34C could came from - from the frequency your sensor transmits on
And in Australia that would be C=433 MHz
A thorough study of the MUST READ thread will provide you with some more detailed insights ;)
the customized server posts and the Ecowitt Gateway API provide real voltage for the WN34/WN35 series. Due to historical reasons, there are at least three types of providing battery info: normal/low, 1-5 (6) or current voltage.
The 2.06 V are a bit strange for normal alkaline batteries - but if you use some Lithium batteries that should be OK.
And why would the battery voltage change so fast ? These batteries can hold for up to two years => no short time change in value to be expected
-
the soil_temperature should correctly be named user_temperature, but as the possible 16 soil_temperature sensor places are not used, only 8 out of 16 soil moisture and 8 user temperature - it doesn't matter for the name.
The ecowitt integration does almost everything right - a weird side effect of the programmer obviously not knowing the reality they program ;) is that the battery status of a WH45 5-in-1 combo sensor has 6 tiers and tier 6 means running on DC. HA translates that into 120% :roll: - but imho that's a beauty thing
On my laptop some of the (already renamed for that reason) sensor names are truncated, but I can live with that, as hovering with the mouse pointer over it, it displays the full name.
[ You are not allowed to view attachments ]
EDIT: don't miss my last post before the page break (and before this one) - it might escape your attention
-
the customized server posts and the Ecowitt Gateway API provide real voltage for the WN34/WN35 series. Due to historical reasons, there are at least three types of providing battery info: normal/low, 1-5 (6) or current voltage.
The 2.06 V are a bit strange for normal alkaline batteries - but if you use some Lithium batteries that should be OK.
Ok so the batteries are 1.5V AA LR
I just used my multimeter on a fresh battery from the same pack, and it shows 1.59V. So 2.06V doesn't seem to make sense...
And why would the battery voltage change so fast ? These batteries can hold for up to two years => no short time change in value to be expected
I guess I expected the voltage sensor to be updated at the same time as the temp. So even if the actual voltage hasn't changed, HA should say "last updated 1 min ago". Or does the sensor only send a new value if it is actually changed ?
Connect your console (GW2000) temporarily to http://ear.phantasoft.de - first connect via browser and read the instructions
Contrary to the http call, the custom server posting uses the live data as is - the same way as the local Ecowitt Gateway API provides it - there comes the voltage from.
ear.phantasoft.de also shows a voltage of 2.06
-
I guess I expected the voltage sensor to be updated at the same time as the temp. So even if the actual voltage hasn't changed, HA should say "last updated 1 min ago". Or does the sensor only send a new value if it is actually changed ?
where would HA know this from ?
The WN34 sensor sends an update to the console every 77 seconds (see MUST READ thread) - whatever and how often (customized posting interval = xx seconds) the console reports within the next 77 seconds is the old value, afterwards the new value (which may be the same value).
When the console reports 2.06 V, then that'S what the WN34 sensor reports ...
And the customized post is just what the console knows.
If there is a " culprit", it's the WN34 sensor.
-
If there is a " culprit", it's the WN34 sensor.
Fair enough. It would be nice to get accurate battery measurements so I could get HA to notify me when the battery is on the way out
From your experience with Ecowitt service, are they likely to replace the sensor based on this kind of information (it's brand new) ?
If not, Amazon will usually let me return/replace it...
-
I would first try with a new, different battery. Let the sensor be powerless for 10 minutes before inserting the new one.
Mine show 1.46 and 1.6 Volts - so if at all, it may be a sensor item issue and not a series issue.
If you purchased it via the Amazon Ecowitt Store, you should return it there if the battery change as described above doesn't show a change. Ecowitt are usually quite customer friendly regarding not (properly) working items.
-
I would first try with a new, different battery. Let the sensor be powerless for 10 minutes before inserting the new one.
Mine show 1.46 and 1.6 Volts - so if at all, it may be a sensor item issue and not a series issue.
If you purchased it via the Amazon Ecowitt Store, you should return it there if the battery change as described above doesn't show a change. Ecowitt are usually quite customer friendly regarding not (properly) working items.
So a different (new) battery didn't make any difference unfortunately.
I also noticed that the WN34 would drop signal every 1-2 days for several hours at a time (from 4 bars to no bars, and no reporting), and also have long periods of not reporting at times.
I ordered a replacement, and the new WN34 shows a battery voltage of 1.6V, which is good.
I also moved the GW2000 to a 'better' location (direct line of sight, only one wall/window in between).
With the new WN34 and the old WN34 right next to each other, and the GW2000 in the 'better' location, ironically the old (faulty voltage) unit has so far had better signal uptime !!
Would there be some issue with two units right next to each other in terms of interference ?
-
interference is unlikely - if you want to exclude it resp. minimize the probability, remove both batteries, reinsert it into one - wait 30 seconds and then reinsert it into the other. They should post every 77 seconds - and as they were initialized 30 seconds apart from each other, they should also post at different times now.
-
And why would the battery voltage change so fast ? These batteries can hold for up to two years => no short time change in value to be expected
So the replacement WN34 does report battery voltage regularly to HA; I haven't quite discerned the time pattern (but the push interval to HA for all data is a little random from what I've seen)
[ You are not allowed to view attachments ]
For a 1.5V battery, what is a sensible voltage alert to set up for when it needs to be replaced ?
-
1.2V warning
1.1V replace
-
1.2V warning
1.1V replace
Thanks !
-
Hello, I am new in Ecowitt and Home Assistant as well (I have Hubitat so far but will set up HA soon).
Could someone advise me if Ecowitt integration can be done just via WS3800 or if it is necessary (or better) to have the gateway, like GW2000? I like that WS3800 has a display and it has Wi-Fi as well, so I don't understand if it includes all features of the gateway or if this is somehow limited (for integration purposes).
Thanks for your reply!
-
every modern Ecowitt console with WLAN/WiFi capability also has the customized server functionality (latest firmware recommended). So you don't need a separate gateway if you own a WS3800.
Do you read the HomeAssistant chapter in our WiKi ? http://meshka.eu/Ecowitt/dokuwiki (http://meshka.eu/Ecowitt/dokuwiki)
It answers many questions 8-)