Conversation
|
Thanks @nachogarcia |
|
Do you think this might solve #6 ? |
|
Not sure, if it's the case at least we might have some trace now. If you plan on maintain this repo, maybe you could talk to have yours in HACS. |
|
I would very much prefer @anotherjulien to come back and merge our changes into his. I will be moving out of my flat in the next 2 years and I will have KNX then, not bticino. So I am not the best candidate for its long term maintenance |
|
Also, I am really not a python coder. All this is as trial/error + AI. I have also patched some stuff in ownd library which would be good to include, but since this is taken from pypi, Id have to publish my own fork there. I did find however that https://github.com/smf666/OWNd pushed his as ownd2 so I created PR on his repo to merge my changes and publish them. We should then switch dependency to that until @anotherjulien fixes his ownd. @smf666 has also his own fork of MyHome which includes some fixes and seems like proper zigbee support. I wanted to merge his commits, but he implemented cover timings functionality which conflicts with one of PRs merged into my repo. I think the version I use (from @andrea-parisi fork) is superior as it handles different time up and down which has been a gamechanger when it comes to accuracy of % calculations, but the other repo also somewhat works with zigbee blinds if I understood correctly? On top of that the repo has really weird diffs when it comes to commits, it shows basically every line as removed and then added which makes it super hard to diff visually on github. All that being said, I am not a python developer and while I can piece together things from other devs, merging @smf666 or even debugging in further detail the issues goes beyond my python skillset. Maybe you can have a look if you want to try and merge this. Cheers! |
|
Hello! Some of those changes breaks way that group lights are handled. For example: for every light on/off command, ownd opens a new session, sends the own password, then the command. the problem is that the homeserver can't handle so many connections and some commands are not sent. before the commit, there was only a login/connection with a queue. |
|
@gdluck what changes do you mean? I dont see in my log that a new session would be initiated for every light command |
|
Try to open/close a group of lights and see what is happening after this pull (with debug activated) |
For single light, works as expected. What do you mean by group of lights? Like in a bticino area? Or group in HA? Sorry, but I dont understand |
|
|
Sorry, I cannot reproduce, it turns off within a single session: @nachogarcia can you reproduce this? |
|
Also I cannot imagine what this PR would cause, as its mostly just error handling. There is one change here: But still I dont see how it would cause what you describe. Did you confirm 100% that without this commit the issue does not happen? |
|
I just reverted to a version before this merge and now is working correctly. Still many auths but no command is lost. |
|
Oh. I've made a commit to fix exactly your problem with ignored commands: gdluck@bb0c69a And since then, ignored commands are gone. But with those merges, I restored the bug. |
|
well your commit explains what is going on. You are closing and creating new connection with every request. that is definitely not how it should be done and its the true reason for your issues |
|
But is the only way is working. I have ~70 sensors (35 binary and 35 thermostats with temp + humidity) that are sending data and creates the issue with ignored commands. Something makes the send_buffer to ignore/fail commands. |
I can confirm @nachogarcia that it does NOT fix the issue :( |
I'm not a developer, I learned just enough of Python to produce this pile of code a few years ago. It has been honestly exhausting trying to keep up with everyone coming to me with their specific - setup dependent - issues and asking for a fix. Or feature requests that I do not have the hardware to test. People complain that OWNd makes a new connection for each command? Well... it needs to... because command sessions have an undocumented lifetime, that is dependent on the type of gateway you have. And you cannot know when the session is closed by the gateway because it simply stops responding instead of closing gracefully. Without engineering documents from BTicino/Legrand, there's only so much you can do. Quite frankly, MyHome has been the biggest regret building my house. |
|
Thanks for your work @anotherjulien and @michnovka. I think it this problem can be solved with a silent fake ping-pong when connecting and a bogus command after reconnecting. I'll try some fixes and let you know. Also, if I increase the workers - the queue is processed quickly and I didn't notice any more ignored commands. |
|
@anotherjulien thanks for letting us know the state of things. I totally understand the lack of motivation to implement features for hardware which you dont own and to fix bugs which you dont experience. I think since there are no people who would like to take over the project and show some commitment on maintaining it, it will be as it is - multiple forks each fixing the issue that bother the person who forked. |
|
I can't say, either I've never encountered the problem, or it is so infrequent that I did not notice it. |
|
Its not unexpected, it sends events because it is queried on command session. By
Then, the response to these messages is series of status updates for heater followed by ACK in the end. This is corresponding to the manual also: WHO_4.pdf See here what it looks like with proper logging, it is clear from there: |
|
I see... so it's a collision. New commands are sent before all the replies that the heating system sends on the command session are read. |
|
yea, my code fixes this, check this PR. It works reliably |
|
Any benefit for a Where did the need for multiple retries upon |
|
From the OWN_Intro_ENG.pdf documentation:
So we should: I acomplish this by limiting max number of retries |
|
ok, makes sense! |
4 participants
As requested in anotherjulien#155 (comment)