By the way the wittboy firmware itself is independent of the receiver if i remember correctly and can.only be updated by plugging a usb cable into.it directly.
1 Like
The data would also point to that, but good that someone else is also of that understanding.
Bit of a shame you need to:
Looks like i am running the latest still at 1.33 from apr of this yr (see dump above). I updated it when i installed it in fl last may.
1 Like
I confirmed that the data feed is still configured. I turned on first Trace for a while and then Debug, The below is all that came through. I tried changing the MAC to the IP and that didn't help either.
Doesn't look like the data feed is reaching the HE device. Do you see any other logs in HE indicating a message was received and it didn't know where to send it? Take off any filters you may have on the logs page and wait to see if you see something like that.
Otherwise, if you don't see any logs, post a screenshot of the data feed configuration in the WS View App and I'll try to see if there's anything wrong there, though it would seem odd if there was.
If there's nothing there, the only other option I can think to try would be restarting the gateway...
Here's the data feed configuration. I've already tried restarting the gateway. Wish I hadn't updated.
Try setting the Server IP to the IP Address, rather than the server name.
2 Likes
Yeah, that did it. I've noticed that hubitat.local seems to have a really laggy response since I updated to 2.3.6.136.
1 Like
Glad you got it working.
Have you only ever relied on having that set within the HE hub?
Do you only have one HE hub?
Did you go from 2.3.5 to 2.3.6.136, or an earlier version of 2.3.6?
Sorry for all the questions... just feel it would be good to provide some feedback to the engineers, if there is anything worth investigating on their end.
Not sure what you're asking. I used to use the IP. The router uses a reserved IP for my HE. And that worked great for years until the router — unfortunately Xfinity (please no comments or suggestions... it is what it is) — changed the IP regardless of the reservation. I couldn't force it to change the IP back, so I have a new one, and it's reserved again. But since I didn't really trust it I changed most places that used the IP to use hubitat.local instead. And that has worked fine for at least 6 months. I don't remember exactly when I made that change.
Yes. Have a C-8.
I went from 2.3.6.135 to 2.3.6.136. I didn't notice any lag before 2.3.6. I think it started when I updated from 2.3.5 and I was chalking it up to the UI changes. The Ecowitt gateway was fine even after 2.3.6.136. It was the last Ecowitt firmware update that caused that problem. I thought.
Not a problem. I'm happy to help out any way I can. Let me know if you want any other info. I wish I had been paying closer attention to what happened in what order when.
1 Like
BTW, I'm seeing this in the logs now but I'm assuming it's OK since everything seems to be working and it is updating every 2 minutes.
Ah, yes, should have clarified that... I have my host names configured under a .local domain through a DNS running on a raspberry pi, was just wondering whether you have the same setup or relied on a setting in the HE hub where you can nominate the name. Based on what you have described, it is the latter.
Feels like there are a few things that could be at play, and I'm leaning towards EcoWitt, or at the very least some kind of interplay between the two. Probably not worth raising it with HE staff at this stage, I'm sure if there is an issue other users will experience it and report it.
Yep, one more attribute I should try and pick up on. You can manually turn the logging (Verbosity Level) back to warning or error (or something else) if you want. I think the drivers are set to turn off the debug / trace logging automatically, but not 100% sure. Probably best just to update it yourself back to whatever level you want.
1 Like
I recently switched to Sharptools for my dashboards and ran across an issue in my Lightning Sensor that I'm trying to figure out. When I added it to my dashboards, one of the attributes lightningDistance is reporting in km instead of miles. I have my hub set to Imperial. I'm reaching out through that community for help, but I'm curious if there is anything in the driver that is pushing it in metric vs. imperial. If so, is that something I can change? or am I going to have to break down and learn metric (eee gads!!)?
In the ecowitt app it reports as miles, but in Sharptools its coming across in km
1 Like
Looks like a bug in the driver never noticed but the attribute apparently is coming out in km and needs to be converted. Never really liok at it as the sensors are crap and either report nothing ar way.too much.
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
