RollerTrol blinds not working (was: Nexa Door bell being read as light switch)

[Mastiffen]

I have recently started using Node-RED on a Pifor most of my home automation hardware, and RFXtrx is of course one of those things. Very nice stuff! But one thing is confusing me: The Nexa LMLT-711 door bell button is not picked up by the door bell node. Only by the light switch node. Is this a problem with the switch or a bug?

[maxwellhadley]

There are a few oddball types of doorbell which actually send lighting1 messages and are handled by special-case code. I don't recall seeing this device as one of those, but it will be easy enough to change if I have missed it (or it may have been added in a recent RFXtrx firmware version).

My main development machine, with the RFXCOM SDK documents on it, is currently down waiting for Meltdown/Spectre patches to be available. I'll get back to you later...

[Mastiffen]

Thank you very much for the quick answer! This is not something new, but come to think of it this may actually be an RFXtrx problem. This is what it used to look like:

RFXtrx.Type: AC address: 006d25a2 unit: 01 command: group on

I think I only separated it in EventGhost's RFX plug-in because of the group on command. Sorry...

[maxwellhadley]

The other lighting1 doorbells send a 'chime' command byte from the RFXtrx, but it looks like this one sends a 'group on' for some reason. You can get Node-RED to log the actual bytes received for this (and all other) RFXCOM message by setting the environment variable RED_DEBUG to "rfxcom" before starting Node-RED.

Have you tried sending a command from Node-RED to ring the doorbell? What command do you have to send?

[Mastiffen]

I am not at home now, so I don't have any doorbells here. I expect be home again Saturday. Here at the cabin I use those buttons for other purposes, sort of like a regular AC button with no off, only on. But yeah, this one sends a group on. I guess the /0 instead of a regular number means group on in Node-RED. I will check what I need to do to firethe doorbell from Node-RED when I get back home and let you know.

[Mastiffen]

I am not at home now, so I don't have any doorbells here. I expect be home again Saturday. Here at the cabin I use those buttons for other purposes, sort of like a regular AC button with no off, only on. But yeah, this one sends a group on. I guess the /0 instead of a regular number means group on in Node-RED. I will check what I need to do to firethe doorbell from Node-RED when I get back home and let you know.

[Mastiffen]

Hi again! Sorry, it took more time before we went home then I expected. The door bell actually fires on group on. So it seems it's not following the conventions for that.

But I'm interested in the environment variable, because I have some RollerTrol blinds that doesn't show up in the node. According to the Tellstick node they are of the Hasta Selv-Learning format. Is it possible to add support for them? I'm guessing that I need to capture bytes for it in that case, so I can give you that. Where do I set "rfxcom" as a variable? Is that in a config file somewhere?

[maxwellhadley]

Looking at the RFXCOM user guide (v 5.43, page 11) there are two types of HASTA blind motors. I suspect these are the 'new' type, in which case you must have the type 2 firmware loaded into your RFXtrx, and you must enable BLINDST0 in Rfxmgr, before you can receive command bytes from the existing remote control, which will give you the ID. It's probably best to use RFXmgr to get the ID bytes, as you will almost certainly want to disable BLINDST0 reception afterwards - enabling this protocol disables reception of ALL other protocols!

If you use RFXmgr to get the ID, you don't need to set the environment variable to get the received bytes. The device address to use in Node-RED will be something like BLINDS_T0/0x1234/2, where 0x1234 is the device ID from RFXmgr, and 2 is the unitcode number from RFXmgr (it looks like each remote can handle multiple blinds motors, identified by a unitcode 1 to 15. As usual, 0 unitcode means 'group')

Setting the environment variable is different depending on what operating system you are using: MacOS/Linux or Windows.

[maxwellhadley]

Did you get your RollerTrol blinds working?

[Mastiffen]

Sorry, I hadn't been at the cabin for some time. And when I got out here Monday a bunch of personal stuff happened. But I will try to look at it the coming week!

[maxwellhadley]

Any news?

[Mastiffen]

I apologize... It completely disappeared for me! I checked now, and I have the type 1 firmware (version 95), and even if it showed the BLINDST0 as a disabled protocol. So I did try to set it with

npm run set-protocols -- --enable BLINDST0 --save /dev/ttyUSB0

But it did of course not work. Two things puzzle me: Can I put Type 2 firmware in this unit?And why is it not working with this firmware, when it did work when I had it connected to a pc with EventGhost and Krambriw's plug-in?

[Mastiffen]

I am wondering if I could swap my home RFX and my cabin RFX. At home I don't have anything that needs the newer E version. But still shouldn't it be possible to run the curtains when EventGhost can do it?

[maxwellhadley]

Sorry for the silence - I've been very busy recently (and still am). It certainly should be possible to put type 2 firmware in an 'old' RFXtrx433. The only real differences are the set of protocols supported. You should be able to use the latest & greatest version 1025. The one thing not to do is to put 'E' firmware into an 'old' device, or vice-versa. You need to use rfxmgr.exe to re-flash, but it's quick and painless.

[Mastiffen]

You're not the only one being busy! 😀 Thanks for the tip! And rfxmgr.exe was what I always used when I had the thing connected directly to the automation VM, not a Pi with Node-RED. I'll try that when I get the time.

[maxwellhadley]

Since it's all gone quiet I am closing this issue