I already thought that. It’s to bad that it’s not possible for home assistant. Yes it’s something with RFXcom or Somfy.
But for now it’s already an improvement for inside HA that the state is changing.
For the remote I will take a look in the future.
What I still do need, is somebody with a cover that supports the Siemens/LightwaveRF protocol (the ones that can be added with automatic_add:) to see what command is given for that protocol. Updating the state with a remote should work for these devices.
I checked the code in pyRFXtrx package, and it looks like the commands are either (Open, Close and Stop) or (Up, Down and Stop). For now, I added both in my updated github, so if somebody with such a cover could test it and send me the debug message that looks like that looks like “Device_id: 09979a6_11 device_update. Command: Open”., please do.
I made an update to the code that adds a state to rfxtrx cover devices on my GitHub. Could someone with a cover that supports the Siemens/LightwaveRF protocol please test the code,.
Changes
I think the last three are the commands the Siemens/LightwaveRF protocol is using, but I’m not 100% sure.
Could someone please test
For the RFY protocol, the first two work (tested), the last one won’t, due to limitations of the RFXcom device, see discussion above. But I need someone to test it for other protocols, like Siemens/LightwaveRF. Instructions are on my GitHub page. After a successful test, I will add it to Home Assistant.
Thats what I did, I’ve got the Xiaomi WXKG02LM switches in every room and they double up as light switches (on tap toggle each button) then double tap the left button and the blind goes to the my position, double tap the right button and the blind goes down, double tapp both buttons at the same time and the blind goes to its highest position.
I’ve got input_selects that keep track of where the blind is (MY, OPEN or CLOSED) and I use that for the state. I have input_boleans setup (on for MY position and off for closed) and I control this with Alexa so if I say Alexa open Living Blinds via a routine it turns on the Living Room Blinds bolean and sets that blind to MY etc.
I’m still looking for someone who want’s to test the change, especially updating of the state with a remote (not RFY). See two posts up. So, if anyone could help me with a RFXtrx cover that is using the Siemens/LightwaveRF protocol, that would be very helpful.
Ernst
Downloaded from your git-hub and installed as a custom component.
All looks fine open and closed report correctly and are persistent after a reboot.
The stop button changes the state to open which makes sense as if you have hit stop the blind is probably not fully open or closed. The only time it’s incorrect is when you hit stop when the blind is fully closed its says open which is incorrect but I can’t see how you can code around that situation and your current solution is the best option.
Good work and thanks.
I will keep it live for a few weeks and report back if I have any issues.
Hardware/Software:-
Rpi Custom Install Python Virtual Environment 3.7.3 H.A 0.104.0
USB RFXcom Transceiver
Bofu 433mhz blind motor (Blinds 0 and Blinds Tx protocols)
Dave
@david_b Thank you for testing. Hitting ‘stop’ will indeed report back as ‘open’, also when it is fully closed. Unfortunately, as you also say, I can’t do this differently, due to limitations of the rfxtrx protocol (it can’t report a state, it just receives commands (one way communication). I agree that this is the best option we can get.
Just to be sure, did you test it with a remote, not with the buttons in home assistant?
I will make a PR somewhere coming week, hopefully included in the next release.
@Ernst I’ve update to version 104.0 and I see that the state was not changing this morning. Or do I now have to delete the custom component because there is an update in this version?
Could you try to download the files from my github again and put them in your custom component folder (just overwrite them). I updated the files on my github a few days ago to have all the changes that are in 0.104, as well as the additions to get the state for covers. @david_b is reporting that it worked fine for him, but he has downloaded the updated files. Hopefully, that solves the problem, let me know.
I’ve download the new files and replaced them.
This morning they came with the state update when they opened. So that’s working again.
Thanks.
Great. Thanks for reporting back. Pull request is submitted.
Hi @Ernst I’m using Louvolite Battery Motorised Blinds (same as Dooya) Blinds T6 (under Blinds1 in RFXmngr). The states are changing when used in HA but not when using the remote.
PS: I had groups of blinds in some areas which already report state but your update appears to have fixed the state for individual entities… well done 
Thanks for testing. Could you add debug logging (see instructions on my github) and post the debug messages from the log when you press the remote? It should show the command I need to add.
I also looked in the RFXtrx manual, and I’m not exactly sure if this is the model you have?
Transmitting (T) means that your RFXtrx433 device can only send signals, while RT means receiving ( R) and transmitting (T). This depends on the device you have and on the firmware you have installed. In order make the state change when using the remote, you need to have a cover and firmware that has RT in the table.
For the above mentioned cover, this means that it will only work on a RFXtrx433XL, with the right firmware version (ProXL1). The type2 firmware, which can be installed on a RFXtrx433e can only be used to receive the id, not to receive the command (open/close/stop) apparently (see the note in the table).
You also mentioned T6. For T6 covers, it looks like you could also use the RFXtrx433e, but you need to have the correct firmware (Pro1 or Pro2).
So, an important question is, what firmware version do you have installed on your RFXtrx433 and which hardware version do you have (RFXtrx433e or RFXtrx433Pro). See the table below for which firmware can be installed on which device.
It is also mentioned in the RFXtrx manual that to receive signals, you should enable the protocol. So, please check that the protocol is selected in the RFXmngr.
Hi @Ernst sorry for delay. I have the RFXtrx433XL and your right, it’s BlindsT0 i’m using for the rechargeable blinds (sorry for mixup!). Will get back to you as soon as I’ve had a chance to do more testing and gather logs. Thanks!
ok, let me know. Make sure you have the correct firmware and also make sure you have enabled the protocol.
Hi @Ernst ,
I think the best way to be able to know the real status of RFY (Somfy) blinds is to use another entity to know that.
I’m using Aqara Door Sensors and I’d like, as is already possible on other type of “cover”, to setup their status using the value_template property.
Do you think, as that’s an already existing option on other type of cover on Home Assistant, it would be relatively easy to decide about their status (open/closed) using one of these binary_sensor entities?
Hi @tcircuns. Yes, you will have to use a different sensor is you want to know the status, when using the original remote. A door sensor should do the trick.
I don’t understand your last question. Do you want to update the state of the rfxtrx cover entity, based on the state of the binary_sensor device? I guess that should be possible somehow, but I’ve never tried. I think you could use an automation to update the state.
Note that the PR hasn’t been merged yet. It’s still waiting for the review.
Hi
I maybe found a bug. I see the state in HA but when I using the cover.close and then cover.stop I see state Open.
That is “as designed”. If you press stop, it assumes that the cover was moving (either going up or down), and that you have stopped it before it has fully closed (or opened). Unfortunately, RFXtrx signals don’t send the actual position, so there is no way to detect if it is fully closed.
Therefore, I decided to assume that if you press cover.stop, that it is still open (or at least a little bit open). Only cover.close will report back closed.
Unfortunately, the PR is still not reviewed. It has got the label “needs review” last week, so we have to be patient, I guess.
The PR is accepted and should be available in the next release (0.109).
