Hi, @bpaauwe,
I see your incorporating my suggestions into v8. It’s looking really good.
2 Likes
Good job on 1.0.0.8.
Did I see that it’s now updating the nodesetup files?
2 Likes
Yes, but you still need to reboot the ISY for them to take effect. I think UDI is working on fixing it so the reboot won’t be necessary in the future.
3 Likes
Bob (@bpaauwe),
Some suggestions as I’ve been working with these devices for months
Move the heartbeat from the “hub” node to the “device” node.
Add a checkbox to turn on the “diagnostic” node.
Add a checkbox to turn on the “rapid wind” node.
This way, for the 99%, users can turn off the useless information in the “hub” and “diagnostic” node and cut out 20 unneeded calls to the ISY.
I’d like to be able to turn off all non-weather related data.
Please.
1 Like
You don’t need to enable hub data to get the heartbeat. The hub node is always created and the heartbeat is always updated, but the rest of the hub data is only sent to the ISY if you enable it. At least that’s how it is supposed to work. I don’t have a hub yet so it’s all written based on the docs and feedback. The heartbeat is a node server heartbeat, not a per device heartbeat. The other option would be to have a new node type that is just the heartbeat.
Having the diagnostic (or probably better stated, device data) node be optional was part of the plan, just not implemented yet.
The “rapid” checkbox should function for every station. If it isn’t checked, you shouldn’t be getting updates even from the hub. The default may be to enable it which will create the node on the first rapid wind message. I’m not real sure of the behavior since my simulated hub doesn’t do rapid wind updates. If there’s something that seem off in the behavior here, let me know what you’re seeing and describe what you think it should be doing.
2 Likes
Geez… I knew that; I do the same thing in my driver code. Too much going on and trying to do too much in one day.
1 Like
Bob (@bpaauwe),
This is actually a normal state for the one that shows failed. It detects noise and reports it.
I added this as an issue and pushed some small changes for 1.0.0.10.
1 Like
For Lightning Noise and Lightning Disturber it will report “Triggered.”
This is pushed for 1.0.0.10.
1 Like
Bob (@bpaauwe),
I see you have added a lot of valuable features in v10. It’s looking real good. The Sensor Status is much better. I am going to attempt to simulate a failure by lowering power.
2 Likes
You’d have to create a pull request so I know where to pull from. But you have it in your local repository, just go ahead an push it to master.
2 Likes
.10 is looking good. I like changes and the logging works great. I loaded the node setup files and restarted the admin console. It seems there is no reason to reboot.
I’m going to go through the code this week and I’ll make a readme file.
Great work.
1 Like
Thanks,
I did create a README at one point, but then I pushed some changes to github and blew it away.
1 Like
Ha… I’ve done that. Life is good in these United States.
1 Like
I’ve been tracking the last update field for a little while and have noticed at random intervals that the last update field will increase past 90 seconds. On average the norm has been 0 ~ 90 seconds before the counter will reset back to zero.
My specific question is what does this metric impact?
As far as I can tell there is no missing data which as a lay person I would expect to see somewhere. But as far as I can see nothing is missing and would like to know the relevance of this data field. If a person takes this field literally it means the last time the sensor / hub received an update in data was X seconds whether it be 0 to what ever value seen.
Moments ago I captured a last update which exceeded 1710 seconds which is a far cry from the 0 ~ 90 seconds normally seen.
There is no “Last Update” field in WeatherFlow data.
1 Like
before stating exists or not … can you tell us where you see this ?
1 Like
Sure, this data is represented in a new application created by Bob. One of the fields is the last up date field as seen in the image capture the data packets were not seen for 1710 seconds. Reviewing all of the API documents this specific metric is not called out.
Perhaps its something else like the last status time?
Regardless of what the name is called if this has to do with actual data packets I don’t see any missing packets. If this is more like a heart beat where its not directly related to the data packets but more inline to other higher level operations I will mark this down as less important in my future alert programs.
You need to direct your query at Bob as that is a metric that he created.
1 Like
The Last Update is tracking how long it’s been since the node server received data from the hub (or websocket) for a particular sensor. It increments the time every 30 seconds (same as the heartbeat) and is reset as soon as it sees data. Thus it should bump up in 30 second intervals. While it would look nice to do 1 second intervals, that places quite a load on the ISY to update multiple values every second.
This was Bob’s reply so will need to find out why the counter exceeded 20 plus minutes. Yet data was still received by the ISY Series Controller.