-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[TODO]: Async #150
Comments
also we should rename to power_usage_<mac> for backward compatibiltiy |
I've just tagged as a prerelease version of the integration: https://github.com/plugwise/plugwise_usb-beta/releases/tag/v0.40.7a1 |
Installed 0.40.7.a1 in my production box 8+1 nodes took 6 minutes to initialise all entities migrated correctly indeed, retaing history and settings during initial energy collection got a few: No subscriber to handle CircleEnergyLogsResponse, seq_id=b'A290' from 000D6F00009964FC no 'warnings' after |
0.40.7.a1 both unrelated. All rotate nicely at 00:00 CET, some very low power usage have a small hickup after the reset ( but maybe just waits for a pulse to happen) this particular one "lost" updating for some time now... will wait if it restores in the end (putting something in the microwave might help) I think both warning sets are mitigated by my PR with the await instead of gather and the 5 resend instead of 20 |
installed [v0.40.0a6] through [v0.40.7a2] will activate INFO logging to see if there is a "logic" to it still graph "issue" of the daily reset of low power using nodes, i doubt of it is solvable and due to the PULSES per Wh resolution: |
I do see some |
Got in a intereseting state today: longer time.... something " broke on 13:00 for this node but for other nodes it is different reset to a1 but no change my cirle+ is still going strong by my circles are bugging.,.,. I will move my cache and compare removing the cache helped.... values seem better... diff shows that the energy_collection in the cache is sorted inverse... might explain why the things went stray at 13:00 sunday, that was the first restart after installing .a2 |
Going back and forth to older version with or without removed cache doesn't solve it I will move my stick to my dev vm if I can replicate the issue there. |
Looks like during a "rollover" of the current pulse counter into an energy log record, at least one of the energy log records is not used in the recalculation. Debug logging during a rollover should reveal what's actually going wrong.... |
Tried to debug it yesterday.... saw some negative pulses but those dissappeared, moved the stick back to my prod env... issue gone.... got me baffled |
Todo
The Async branch is working stable at my end but that is a set of 1 Circle+ and 8 Circle -F types
I must say that I can only tell AFTER the first intial run where the caches have been filled up so you do not get a load of startup messages.
I have seen odd energy baviour at a point in time where I flushed the cache and woke up with this pattern:
but after restart it settled fine and keep running
Here are a few of my observations:
The sawtooth in the above image was caused by the counter rollover and then missing the slot 4 download, that is gone
The energy usage resets bases on server timezone (when my Ubuntu VM is in UTC it rolls on 01:00 in the graphs, CET rolls correctly, as the python-plugwise_usb does no home assistant maybe we should tell it on startup about the HA timezone to correct the last reset time to align in the graphs
vs
When a node has nothing attached to monitor it will not show data:
Power pulse counter for node 000D6F0000995D02 of value of -1, corrected to 0, when you attach a load everything comes back
Strange thing is that the Circle+ ping times are a lot longer (80ms+) then the circles....(20ms)
my branch is till a bit to chatty on energy as I was monitoring the sawtooth but I cannot test any further as I do not have SED or other plugwise equipment.
I do not know how the relation is with my underlying zigbee network, maybe it behaves different in less stable networks. I can up the plugwuse_beta PARALLEL_UPDATES up to 8 without having issues. Also since i implemented one continious loop for reading and queing/writing I not need any sleeps and I do not have a lot of "network" issues in the normal run. When all nodes are queried for a lot of missing addresses there of course more congestion.
The text was updated successfully, but these errors were encountered: