put some debugging in..
very strange.. the fx to determine if we are metric or not checks on the parent and the parent of the lighning sensor is correct just like everything else but in this case is returning null..
ie
ok found the problem.. will try changing but if all other numbers are correctg it is going to break lots of stuff. the value for imperial non metric is 0 and it assumes that is null
ie
1 Like
Is that the updated code? If so, that seems like a reasonable approach. Both null and 0 are falsy, so if they are used directly in a condition, they're both treated as false, but with a strict equality comparison they should be considered different from each other.
From what I recall, the == operator actually tries .compareTo() if both values inherit the Comparable class, otherwise it falls back to .equals(), so you should be able to directly use .equals() to force a strict comparison if needed.
From a Groovy Shell (away from my Hubitat at the moment or I would have tested there)...
def a = 0
def b = null
println 'a == b -> ' + (a == b) //a == b -> false
if(a)
println('a is truthy')
else
println('a is falsy') //this path should match
if(b)
println('b is truthy')
else
println('b is falsy') //this path should match
Expected Result:
a == b -> false
a is falsy
b is falsy
ok boiled down to this.. i think it is some sort of bug?
when getting a boolean value from a parent class it is returning true fine but instead of false returns null. so direct checks fail..
ie
good case
bad case
tagging someone else in support to see if this is abug
2 Likes
here is fix.. is the ecowitt wif sensor change the function as follows
private Boolean unitSystemIsMetric() {
//
// Return true if the selected unit system is metric
//
def isM = parent.unitSystemIsMetric()
if (isM == null)
return false
else return isM
//return (getParent().unitSystemIsMetric());
}
// ------------------------------------------------------------
the old is the commented out.. it was getting null
That is an interesting bug. Seems like a minor typo in the code though, right?
private Boolean unitSystemIsMetric() {
//
// Return true if the selected unit system is metric
//
def isM = parent.unitSystemIsMetric()
- if (ism == null)
+ if (isM == null)
return false
else return isM
//return (getParent().unitSystemIsMetric());
}
That being said, it looks like the rest of the sensor code handles the null / falsiness of the unitSystemIsMetric() everywhere else just fine.
It looks like it's only the attributeUpdateLightningDistance which is explicitly comparing it to false rather than using the implicit falsiness of the value directly (like the other functions do). So just updating that one function's comparison would be enough too:
private Boolean attributeUpdateLightningDistance(String val, String attrib) {
if (!val) val = "0";
BigDecimal distance = val.toBigDecimal();
String measure = "km";
// Convert to imperial if requested
- if (unitSystemIsMetric() == false) {
+ if (!unitSystemIsMetric()) {
distance = convert_km_to_mi(distance);
measure = "mi";
}
return (attributeUpdateNumber(distance, attrib, measure, 1));
}
2 Likes
yes typo.. if it were me i would perfer my fix as going forward having a null or unitialized value being evaluated as false is just confusing..
anyway. wonder if it is a larger groovy bug or just something in hubitat
1 Like
Thanks for reporting this @lcw731, and thanks to @kahn-hubitat and @josh for working on it while I slept 
I think I will take on both changes to the code. The fix to the unitSystemIsMetric() to address the underlying issue of null being reported. But I will also update the lightning sensor method, if only to bring it into line with the approach for other sensor values. No need to have them different and be wondering why.
Should have an update out shortly.
2 Likes
I have made changes to the sensor driver, but I would like it if you could test it before I release it (or anyone else who is interested). I still haven't got around to setting up a beta release option within HPM, so you will need to install the updated driver code manually from here:
https://github.com/sburke781/ecowitt/raw/lightningMetric/ecowitt_sensor.groovy
Let me know how it goes and I can release it once you have it working.
Thanks,
Simon
1 Like
Yep, that seems to have fixed it. Will that effect anyother devices?
1 Like
Thanks for checking it out @lcw731 . I also do some testing before releasing it, but I don't expect it will impact other sensor readings.
@sburke781 , quick question, is it possible to get the ecowitt device ID and show it in the device page? I think I have a device or two that for whatever reason didn’t carry over from my GW1101 to my GW2000,. It would make it easier to pin point which devices are which. I’m noticing in some cases the model numbers aren’t correct , so the Ecowitt device ID would make it easier.
Unfortunately I suspect not, but I can check. I think the list you see when you turn on trace logging is the list of data points received by the driver. I"ll let you know what I find
1 Like
Ok, I’ll double-check the logs. I am almost 100% certain I have one sensor that for whatever reason isn’t being pushed to Hubitat. it's a WH32c outdoor temp sensor.
Update: I think it is being pushed, but I deleted it thinking it was the old GW 1101. It is a WC32c outdoor temp/humidity sensor, but it appears to be coming across as a WH25, which near as I can tell doesn’t exist, or at least is no longer in the Ecowitt catalog. A search on ecowitt.com didn’t turn up anything with that number.
Strange... PM me the trace logs and I'll take a look
I’m back to thinking this sensor isn’t coming across and that other thing is the old gateway, last update was in July.. just sent the logs.
1 Like
Thanks. I'll take a look at the code in the next day or two to see what I can find.
1 Like
For info, I have resynced the devices twice and reregistered the device in the Ecowitt app, then resynced again.
1 Like
U need to resync sensors in hubitat
2 Likes
Still odd for the battery reading to come through as WH25... but the resync is worth a try.
