Hi Ron, until Jan has time to maintain the repo, you could copy over de following files to the integration by Alex. It should have all functionality of both repo’s combined.
Copy these files from the repo from Jan to the repo from Alex (overwrite).
manifest.json
cover.py
I truly hope @jankrib hasn’t abandon use (leaving us alone in the dark, with the wolves)… We’re being reminded every time HA is rebooted now - that xComfort will fail when 2025.1 comes along… 
Because I didn’t like the solution for switches in Alex’s version I changed it. My version creates binary_sensor entities instead of switch entities. The binary sensor only turns on briefly when pressed and has an extra attribute which states if either top or bottom button has been pressed.
I can now control automations with all buttons individually. (IF button1 = on AND attribute = top, do this, IF button1 = on AND attribute = bottom, do that etc.)
Great, thanks. I will check it out.
Do you guys also have issues with the integration?
Sometimes the integration stops working, a reload solves this. Once the reload is complete, all recent button presses are send (quite annoying).
I have this integration running on two different HA instances; One is HA-OS running on a Yellow and the other is HA-Core running in a Docker Container. Both has been 100% stable since the first version of this integration.
This is in my opinion a vary valuable and fine integration. I just hope it will continue to be maintained. The first priority now should be to update prior to 2025.1 as we are constantly warned about during every HA restart. Regretfully I’m not able to maintain it myself as I am not a programmer.
@Ron168 Let me know what you think. It shouldn’t triigger on reload. In my testing the binary_sensor never turns on during a reload but even if it did the last_button_pressed attribute should stay ‘none’ until pressed. I only have access to single and double rocker switches so let me know if the 4 buttons rockers work as expected.
I picked up a bunch of different switches of different series, and they’re all working great. (Bottom right switch just has a 3D printed cover.)
I’m getting the hang of this now. It took a bit to really get how Home Assistant integrations work, especially with the xComfort bridge. I’m not a developer, but I’m starting to get it(!). Planning to pushed some new code today that should fit better with the current setup and Alex’s workaround. I might even feel brave enough to have a look at adding the device for switches to the xcomfort library. This way we could upstream this functionality to the main integration.
Alternatively, I’m thinking about adding some extra attributes (position, timestamp) to the switch entities in Alex’s setup. But, I don’t agree with the rocker switches being switch entities in HA. It feels off to me—they should be binary sensors as they are pushbuttons. But maybe its worth it to keep things smooth for anyone already using Alex’s method. What do you think?
Hi,
sorry for the late reply. I don’t come here that often and I’m not spending much time with Home Assistant lately.
I agree, the buttons shouldn’t work as switches. I’m not sure if the binary sensor is the way to go either, they should be push buttons.
For my automations it doesn’t matter, as I simply use the event (sent when a button is pressed).
Do you think it’s also possible to use double press events? So if a button is pressed twice within < 1s for example.
Thanks for your feedback, much appreciated! Hopefully I will have some time soon to do some testing, as I want to add more buttons around the house.
Best regards,
Ron
I just got an Infrared heating panel that is connected with the Room Controller Touch linked to the xComfort Bridge.
I installed the integration and it works as a charm with regards to changing the temperature and modes. Also it reads the humidity and power usage.
I played with the settings and saw the RCT supports two touch buttons that allow for example to switch a light on and off. Most likely this requires an Eaton device that is supported, but I was wondering if the integration can be used to just read out the 2 buttons, so it can be used to control other items in Homeassistant.
Currently i do not see any sensors that represent the touch buttons.
Would you mind elaborating a bit more on the details;
The xComfort Bridge does provide events for button clicks. You can use those through the Alexa Integration and it is possible to loop that back to HA. The Google Integration does not support button events.
Some work is being done to attempt to integrate this also into the current xComfort Bridge Integration by at least two contributors, but progress isn’t complete yet.
Perhaps if there were more request for this feature, it could get some momentum? 
See comments inline
Does anybody have actual private key used in the communication between phone and bridge?
This is not actual at this moment.
https://github.com/epaulsen/xcomfort-node/blob/0881874f416457ffcb4057ce70bed216f9232785/mitm/private.pem
What is it that “is not actual at this moment” ??
Just realized I haven’t visited this thread for a long time. On the switch/rocker implementation, I don’t recall why I chose switch over binary sensor. Neither is a great fit.
I also noticed the issue with the switches firing events during integration startup (I think). Normally not an issue, but sometimes can be. I’ll have a look at your implementation @shifto and see if I like it better.
However, I see @alexbrasetvik now has a cleaned up version of my change (including getting rid of the hub hack) and submitted to the upstream. But it’s still waiting for approval by @jankrib now 6 months later.
I also submitted a couple of my changes back upstream as well, but won’t do much good if they don’t get merged.
For anyone wanting to use my fork, I’ve now moved over to the “dev” branch. It now depends on the “dev” branch of my xcomfort-python fork (until @alexbrasetvik’s changes gets merged and released). It also uses a somewhat different entity naming scheme (so it’s not 1:1 drop in replacement), as I didn’t much like the one in the upstream.
Hopefully we can try and unify these forks a bit 
I must admit that I’m a bit confused about what version is where and how to obtain the “latest-and-greatest” of what is being done by the various contributors.
As long as @jankrib is the chief maintainer, and all merges has to be approved by him (if I understand this correctly?), I surely hope he appreciates the work offered by others and eventually does his bit to move things forward.
For me, this integration has become critical.
Now to a practical observation related to the switch entity; Assuming a starting point where the light is off and the switch is off. Then flipping the physical switch will turn on both the light entity and the switch entity in HA. So far, so good. Then flipping the switch off in HA will also turn off the light. But then, if someone turns the light on using the xComfort bridge, only the light entity in HA is affected (on). The switch entity remains off. Consequently, the switch entity no longer reflects the event that takes place if someone flips the physical switch to turn off the light. The switch entity cannot be used to turn off a light as long as it is already in an off state.
So contrary to the physical switch, which does not seem to have a state value in xComfort, and thus sends an off event if you press off and vice versa, completely independent of its previous state (since there is no state).
Can such a behavior be implemented in the integration for the switch entity? Eliminate state and just provide two action properties/features; ‘on’ and ‘off’ assuming there’s never a need to know the state of a switch.
I know the switch entity has been implemented into the Alexa Skill (integration) in xComfort, but I cannot remember how this work (if it’s stateless or not). They (Eaton) never managed to implement switch entities into their Google Home integration.
[ P.S. How can I find out which version of the xComfort integration I currently have installed in my HA? ]
I think the “latest and greatest” is the version from @jankrib’s github which I believe is also published in HACS. I totally agree we should get changes merged there.
For the switch behavior you describe, I believe this is achievable using events, and it is how I am using it. I.e. the on and off events will always fire no matter how many times you push the physical switch and no matter which state the HA switch entity is in fact in.
That would be an excellent approach, but what events are you referring to?
I don’t see an ‘xcomfort_event’ anywhere in the event listeners list.
Could you provide a syntax sample for such an automation?
It’s not very intuitive. I think you have to manually add the event name and payload to an automation. In case you are using my branch (with swicthes) the event name would be on the format xcomfort_rocker_ENTITY where ENTITY would be the full name of the switch/rocker entity. Event data would be “on”: true for on and “on”: false for off.
Is there any update on the (touch button) topic?
