xcomfortd-go
xcomfortd-go copied to clipboard
Shutter Actuator with Security (CJAU-01/02)
Hi
I have a Shutter Actuator with Security (CJAU-01/02) installed that is controlling an awning The problem is that the up/down/stop buttons is not behaving as i would expect
The down and stop button is available and works, but the up button is only available if down is pressed first The down button acts as long press in sensio
When using the actuator for awning we dont really need the short press, but i quess that would not be the case when controlling blinds
Here is the RF log when using Sensio
Eaton RF config
Home Assistant
Christopher
To my knowledge, you're the first one to test the code with shutters, so here be dragons.
Difficult to say exactly what's going wrong here. I added the stopped
status as well, slightly improving the integration with HA, but I'm not sure if this will fix your issue. Can you experiment a bit with the shutter and send me the accompanying MRF logs?
Same behavior with 0.47
MRF log when controlling with HA
Still not understanding what's going on. Can you turn on verbose mode and send me the accompanying logs from the daemon?
Just commenting on this, hopefully not disturbing anything.... Is it too early to test this, or are the conclusion that Eaton's actuators should be changed with something based on z-wave? I have a 9 blinds (screens) that are guided from Sensio through xcomfort. This has never worked perfect, always one of them being up on sunny days and never the same one. It worked well a while when I could group them together in one DP, but a bug introduced in Sensio removed that possibility, and was never fixed.
The logs all look good. As far as I can tell, the blinds are going down, stopping, going down, (then stopping briefly) and going back up. What is it the issue that you are seeing?
Ping, still wondering about this.
Sorry, my bad not replying. Too busy trying to integrate everything in HA...... My question was related to the challenge I have with Sensio and xcomfort as a whole regarding communication with 8 screens simultaneously. There is often a drop in signals, and one of the screens (rather randomly) misses the signal and don't respond up or down. That will not change with moving from Sensio to HA I expect, but with HA I have more options in programming delays, groups etc. My comment was also related to an earlier comment in this topic, where Christopher was announced as a "first mover" related to shutters in this library. I looks that there is no issues now, and I will put this into work, I hope it is plain and simple, using the shutter button in HA.
Thank you.
It seems the code is sending the correct commands But the control buttons in HA is not available to push
The down and stop button is available and works, but the up button is only available if down is pressed first Alle the buttons should be available at all times
The down and stop button is available and works, but the up button is only available if down is pressed first Alle the buttons should be available at all times
This is how HA works with shutters; when it doesn't let you press up, it's because it thinks that the shutters are already open. The logic is partially described in https://www.home-assistant.io/integrations/cover.mqtt/; xComfort reports only the three states opening/closing/stopped. I don't know if this value is retained across reboots.
My question was related to the challenge I have with Sensio and xcomfort as a whole regarding communication with 8 screens simultaneously. There is often a drop in signals, and one of the screens (rather randomly) misses the signal and don't respond up or down. That will not change with moving from Sensio to HA I expect, but with HA I have more options in programming delays, groups etc.
Not sure if this applies to your case, but the documentation specifies that a group's common data point must have a higher data point number than the individual data points, otherwise status reports from the individual devices may be incorrectly assigned to the group (whatever that means).
Well, Sensio was debugging the whole situation for several hours two years ago. This was - for them - unique problem related toe shutter actuators in a group. Outside the group everything was fine, inside the group there was no response from the actuators. The problem was identified, but never fixed. They got all engaged in developing smart systems for elderly (Velferdsteknologi) and dropped the further development of private systems. I never got my bug identified nor fixed. This is the reason I have bought you coffee in appreciation of the solution you have developed, and I am using this for lights and (hopefully) soon for shutters and heating. One step at a time :-)
Test the code and see how it fares. If the issue shows up with my code as well, try to capture it in the logs, and I can at least let you know if it's fixable on my side.
Well, Sensio was debugging the whole situation for several hours two years ago. This was - for them - unique problem related toe shutter actuators in a group. Outside the group everything was fine, inside the group there was no response from the actuators. The problem was identified, but never fixed.
Digging a little further in the documentation, it seems that xComfort doesn't guarantee that group messages are delivered to all devices in the group. A theoretical solution would be requesting the status directly from the actuators, but for shutters that's not possible. I see only two solutions if this a big problem for you:
- Double checking signal strength and that routing is optimal to all devices
- If that doesn't help, assigning separate datapoints to the individual actuators and not using the group messaging
Thanks. I have left group signaling two years ago, when the bug in Sensio (for shutter actuators) appeared and they wasn't able to fix it. I am also investigating into a third option: Switching to z-wave. Replacing 8 actuators shouldn't be that expensive, and then I have more flexibility. Thank you for your help and interest! ..And your library is fully operable when I testes it on some of my shutters - with the limitation in the system you have described earlier in this thread.
For what it's worth, I have personally had a better experience with Zigbee than Z-Wave, and currently prefer that.
Added this to Configuration.yaml
Buttons always available, works perfect
homeassistant: customize_glob: "cover.*": assumed_state: true
Added this to Configuration.yaml
Buttons always available, works perfect
homeassistant: customize_glob: "cover.*": assumed_state: true
Seems to work perfect. Thank you!!