[RE-RELEASE] EcoWitt and Wittboy Weather Stations And Sensors (Local)

well that doesnt make sense unless something change at that time .. as mentioned either a firmware update or you manually or auto updated the app/driver through package manager or something.. also to change to zero messages had to be sent from the devices, they don't just change automatically.. what is the weather station you are using and are the ecowitt wh31 or other brand.. what do the events in the devices show currently for both temp and any battery reports?.

on looking at mine battery events are only sent when the amount changes.. nothing is sent periodically like some devices.. have you tried putting new batteries in one of them to see if the report updates to 100% ?

also if you are bundled and your main weather station dies. this could could update all to zero.. i am not sure what it does as i never tried it and have never had my main battery die

// If we are a bundled PWS sensor, at the endofdata we update the "virtual" battery with the lowest of all the "physical" batteries
if (bundled) updated = attributeUpdateLowestBattery();

Did not realize that i had my own version of the templates.. your documentation only shows through 6. I am not sure if you have them all..

Here is my copy of the templates. with the addition of the above of 10a.

http://mail.lgk.com/ecowitt1.css

1 Like

Also, for those of you that missed the thread if you have more than one weather station that you want to report to the same hubitat hub you do the following:

Use a port other than 39501 in the hubitat app setup.. ie like 8900 etc. etc.

The IP address that goes in the hubitat app if your weather station is remote is the public ip of your home router. (recommend you get a free dynamic dns for your home router if you are not static public ips ie 192.168.x.s and use that name in the hubitat app configuration, otherwise when your home ip changes this will break).

Then put the following port forwarding rule in you home router that the hubitat is connected to

Forward port 8900 to 39501 with the ip of your hubitat

If you have more than two you can use 8901 etc.

In the hubitat ecowitt configuration you use the public ip address of the router that weather station is on.. If there is a firewall there as well you need to allow port 8900 (or whatever you use) out via tcp.

you can pm me privately if you have issues trying to set this up..

I have 3 weather stations reporting to my main nh hub and 2 reporting to my mi hub.

I also previously added the code to use a ddns lookup to handle the public ip of your remote weather station changing.

1 Like

Reporting temp/humidity regularly/correctly.

Events

If you're referring to the name Indoor Ambient Sensor, that seems to be part of the driver. Component Devices named in respect to their functions.

Names

Mine was sold/packaged as an Ecowitt WH31B.

Ecowitt WH31B


I just installed the new non-mirco version with all the available drivers/procedures the day (06/21) the battery events were captured. There's been no further battery events on the WH31 and WH32 since then.
Maybe I should run a repair with HPM?
Edit: Ran repair, nothing changed.

Gateway Current States:

  • driver : v1.33.0
  • firmware : v1.6.6
  • lastUpdate : 2022-06-25 12:52 PM
  • model : GW1000_Pro

Go.into app and try resync. If tgat doesnt work uiu can remove the device ie pull.batteties out. Do resync. And it will remove it. Then out batteries back.in and do it again. However yiu will break.all rules assiciated with it. So keep a.screen shot of them to be able to fix them.

Pulled the WH31 batteries, changed to channel 3, turned on Trace, ran re-sync.
Not much info in the Logs.
Just zeroes for batt03 and wh26batt, same as the batteryOrg on the Current States.

Logs

image

Looking back at the WH32 (WH26 in the logs) the original Event shows the Unit as !bool. Is that normal?

!bool Event Details

Thats not normal.. do.you do bundling on the wh32 ... you should. Not shown up as its.own device but bundled in with the weather station as the temp and then you can setup with weather underground. Otherwise you cant really use weather underground as you'll have no outdoor temp. Then the batteries come in.under separate attributes .. batteryWind batteryRain and batteryTemp under the pws weather device and in that case battery is set the the lowest if them all with the code i posted above.

The batteryTemp is obviously the wh32 the wind the main weather device and the.rain your rain device.

Also the.older rain devices or the gw1000 appear not to be reporting rain sensor battery. Not sure where the issue lies.

The missing rainTotal attribute saga continues.. in trying to find the missing batteryrain attribute i turned on debugging on on my older wh1000 it became clear why the raintotal attribute has disappeared ... in the firmware upgrade they fffd up and misspelled the attribute .. it used to come across as totalrainin and be stuffed into the rainTotal attribute but now the "R" is missing and it is coming accross as totalainin (see screen shot below) so that is why it is not showing up on newer installs and not updating correctly on old ones.. as a fix for now see the new line added below in the code.

and also this change in the wifi driver i missed

Comparison of the batteryOrg Event Details from 3 devices.

WH32 (Wh26) - !bool

WH31 - V

And something completely different.

WH41 - level

:crazy_face: More irrelevant data.
You're welcome. :upside_down_face:

Did some more.digging..0 is correct for wh31 batteries. They come across in attributes batt1-8
Same for soil.batteries.

1 means battery is low 0 means not low.ie. ok. Voltages are not reported on wh31.

So 0 is converted to 100% 1 to 0.

You will not see anything else. If you truly.want to monitor it recommend you look at the orphaned attribute and write a rule like this:

1 Like

Just changed out some low AA's from a door lock, put a couple in my WH31 for testing.
Did another channel swap/resync. The batteryOrg changed from 0 to 1 with the low batteries.

WH31 batteryOrg Event Details

WH31 Events

Current States

image

Edit 1: And now my Sensors ID page on the Ecowitt app has a little battery icon beside the signal strength with a little red portion at the bottom of the battery.

Edit 2: Put the new batteries back in and the little battery icon went away.

2 Likes

Here is more you ever wanted to know about ecowitt battery reporting.. i did not write this code just interpretting it and also reasearched some on the net.

Apparently in their ultimate wisdom ecowitt reports battery level 3 ways.

  1. as a voltage that you can control min and max in the hubitat app settings but the default is
    min = 1.3, max = 1.65. in the hubitat app this is converted to a percentage then as always the batteryOrg which means original has the raw value reported.

  2. as a number between 0 and 5 again converted to 0 - 100 with the original in the batteryorg and
    finally

3, as you know either 0 or 1 , ie is the battery low yes or no 0 or 1

raw code:

private Boolean attributeUpdateBattery(String val, String attribBattery, String attribBatteryIcon, String attribBatteryOrg, Integer type) {
//
// Convert all different batteries returned values to a 0-100% range
// Type: 1) voltage: range from 1.30V (empty) to 1.65V (full)
// 2) pentastep: range from 0 (empty) to 5 (full)
// 0) binary: 0 (full) or 1 (empty)
//
BigDecimal original = val.toBigDecimal();
BigDecimal percent;
BigDecimal icon;
String unitOrg;

// log.debug "in attribute update battery val = $val attrib = $attribBattery type = $type"
switch (type) {
case 1:
// Change range from voltage to (0% - 100%)
BigDecimal vMin, vMax;

if (!(settings.voltageMin) || !(settings.voltageMax)) {
  // First time: initialize and show the preference
  vMin = 1.3;
  vMax = 1.65;

  device.updateSetting("voltageMin", [value: vMin, type: "string"]);
  device.updateSetting("voltageMax", [value: vMax, type: "string"]);
}
else {
  vMin = (settings.voltageMin).toBigDecimal();
  vMax = (settings.voltageMax).toBigDecimal();
}

percent = convertRange(original, vMin, vMax, 0, 100);
unitOrg = "V";
break;

case 2:
// Change range from (0 - 5) to (0% - 100%)
percent = convertRange(original, 0, 5, 0, 100);
unitOrg = "level";
break;

default:
// Change range from (0 or 1) to (100% or 0%)
percent = (original == 0)? 100: 0;
unitOrg = "!bool";
}

if (percent < 10) icon = 0;
else if (percent < 30) icon = 20;
else if (percent < 50) icon = 40;
else if (percent < 70) icon = 60;
else if (percent < 90) icon = 80;
else icon = 100;

Boolean updated = attributeUpdateNumber(percent, attribBattery, "%", 0);
if (attributeUpdateNumber(icon, attribBatteryIcon, "%")) updated = true;
if (attributeUpdateNumber(original, attribBatteryOrg, unitOrg)) updated = true;

return (updated);
}

2 Likes

I'll admit I kind of lost track a while ago, between actually having a personal life for a change outside of spending time here... :slight_smile: And the stream of great work by @kahn-hubitat and @Ranchitat. I'll need to re-cap through the week on those who are still experiencing issues and changes or fixes that may be required in the drivers, plus any useful info that I can add to the documentation.

1 Like

I submitted an action on github to correct the WH31 battery reporting issue. I made these changes and now my wh31 sensors are reporting 100% battery.

The driver for the RF modules has the WH31 batt[1-8] in with the leaf_batt[1-8]. The WH31 sensor is the !bool value and the leaf_batt is a voltage value. Moving the 'case ~/batt[1-8]/:' to next case statement that starts with 'case "wh25batt":' would put in the correct statement for the !bool value.

Here is the old lines:

case ~/batt[1-8]/:
case ~/leaf_batt[1-8]/:
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 1); // voltage
break;
case "wh25batt":
case "wh65batt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 0); // !boolean
break;

Here is the proposed new lines:

case ~/leaf_batt[1-8]/:
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 1); // voltage
break;

case ~/batt[1-8]/:
case "wh25batt":
case "wh65batt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 0); // !boolean
break;

1 Like

my code already is that way.. was this changed and broken somewhere..

ie

case ~/batt[1-8]/:
case "wh25batt":
case "wh65batt":
case "ws90batt":
case "wh90batt":
state.sensor = 1;
updated = attributeUpdateBattery(val, "battery", "batteryIcon", "batteryOrg", 0); // !boolean
break;

What version of the driver are you on?

I think you may have figured out the reason for this issue @tomobiki.mn. I'd be interested in your thoughts @kahn-hubitat...

ok guys I'm completely lost. My Wh31 started reporting 0 battery a couple days ago. Its been in service for about 3-4 months, clearly that battery is fine. I see discussion above about fixing it, but I'm totally lost on how to do it, could someone help me wrap my brain around what I need to do?

Sorry @lcw731 , I meant to look at this last week. I will take a look after work today.

1 Like