-
-
Notifications
You must be signed in to change notification settings - Fork 17
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
All entities Unknown with Gateway status stuck on Problem #193
Comments
[Edit] My working thesis is that the root cause of this issue at the hardware layer. Two distinct problems are described in the issue. TL;DR: In this case, both can be safely ignored (assuming no hardware problems with your dongle).
This issue occurs with systems that have HVAC, and no CH/DHW. HVAC systems are not as chatty as CH/DHW, and that lack of RF traffic lead ramses_rf to belive that the gateway (the USB dongle) has stopped Rx packets. TODO: I need to adjust the timings for this.
|
@acseven can you ping me a 72 hour packet log please, so I can check what I just wrote is true. I would also like to know that make / model of your kit. |
@zxdavb Hi, sure I've attached a log which includes the excerpt in the OP.
Which kit do you mean?
Regarding your comments, I don't know if I understood your reasoning correctly, but I'm not referring to sparse intervals of RF packets being transferred or not; I mean that it stops altogether and the only way to communicate is by pulling the USB stick and re-attaching it: |
Happened again, stopped at
|
After I re-read your first post, I wasn't sure if I had understood - that's why I asked for the log. The scattered intervals of problems are of no concern, but the longer period is not right. From your packet log (I have inserted the blank line):
You have a problem from just after I would say that this is caused at the hardware layer. This is the same:
But note the 3 Tx of the |
I did say:
This is incorrect:
So (when it fails) the dongle is Tx (or not, you are seeing an echo, not a Tx), and it is not getting a corresponding Rx when you would expect it to. It's the lack of the Rx that is the problem. |
I could code up a USB reset, and a reload - it wouldn't be a high priority. I would start by treating it as a hardware problem. Check connections/ports/etc - then maybe speak to pete.
|
I am closing this issue - do re-open it, if there is evidence that it is not hardware related. |
Thank you for the input. I think I've ruled out the HA host hardware from being the culprit. I've tested the dongle connected to a Windows PC while shared using USP over IP directly to Home Assistant with:
It ends up just the same way as if directly connected to the host machine; so I guess it's likely the dongle. |
@zxdavb does ramses_rf restart itself if the USB dongle is unplugged and reinserted? In the logs above the echos show that there is no loss of communication between the host and dongle. |
No & No. I am not sure how to effect this - periodic USB reset? HA has a 'reload' feature, that is exposed in HA & can be used with automation: see #181 - this is all effected in HA & ramses_cc, via a new instance of ramses_rf.
Yes. So I have run out of ideas. No-one else is reporting this behaviour, that I am aware of. |
FYI, I would be reluctant to implement a USB restart feature:
|
I wasn’t aware of this, it should suffice for the intended purpose. In any case, only part of the issue I’m experiencing is addressed by that. |
Describe the bug
Ramses CC entities status moves to unknown with SSM-D2 from indalo-tech. Gateway's status reads "Problem".
To Reproduce
Occurs randomly.
Please complete the following information:
ramses_cc:
section from configuration.yamlThis is just a portion, it keeps going like this.
Additional context
The issue is sorted by disconnecting the USB SSM-D2 dongle from indalo-tech, reconnecting it and reloading the integration: the gateway is detected as OK straight away and the fan takes a few seconds to get status from all available entities. This has happened a few times now since I got the integration to work with my HRU. I think disconnecting the USB dongle has always been necessary to get it back running, but I'll confirm this whenever it happens again.
One question: some integrations have a automatic reloading feature, could this be implemented here?
Sidenote: an odd sensor is the "filter remaining" sensor, which comes back as soon as the gateway also comes back:
A few seconds after reloading:
Please advise if this seems more likely to be the dongle than something about the integration.
The text was updated successfully, but these errors were encountered: