RFLink binding

[vzorglub (Vincent Regaud)]

Open a new thread to report the bug
You can also do it on github

[cybix32 (Peter Svensson)]

113 are the decimal representation of the hexadecimal value 71. So it is probably a missing conversion?

Peter

[Chris_Griffin]

We dipped into minus temps last night and this fix does not seem to have worked for me. Any ideas?

@Chris_Griffin

@vzorglub

case “TEMP”: result.temp = parseInt(value[1], 16); if ((result.temp & 0x8000) > 0) { // temperature is an signed int16 result.temp = result.temp - 0x10000; } result.temp = result.temp / 10; break;

Done. Bit of a job getting to node_red install directory on openhabian but now sorted. Thanks.

We had a couple of days below 0c last week and was reading 3200degC! Not sure when we’ll get down that low again though. Peaked at 18degC today.

[vzorglub (Vincent Regaud)]

@Chris_Griffin

We dipped into minus temps last night and this fix does not seem to have worked for me. Any ideas?

I know, I had the same.
To be honest, I don’t know. It should work.

I have bumped the gitHub issue but it might be worth opening another one.

[Chris_Griffin]

Just noticed this comment by Fab33 back in Jan. It has a different value on 3rd line. 0x10000 is replaced with 0x7FFF. I have edited rflink.js accordingly and await the cold again!

…may have to stick my temp sensor in the freezer!

[vzorglub (Vincent Regaud)]

Cool,
Post here if it works
Thanks

[Chris_Griffin]

Vincent…

case “TEMP”: result.temp = parseInt(value[1], 16);
if ((result.temp & 0x8000) > 0) { // temperature is an signed int16
result.temp = result.temp & 0x7FFF;
result.temp = 0-result.temp;}
result.temp = result.temp / 10; break;

This works for me.

[vzorglub (Vincent Regaud)]

Yes, my problem was odder than that. I discovered that my sensor was publishing negative value with a different ID. So now I have 2 nodes in node-red for this device…

[curlyel]

Vincent, I think you should get in touch with the RFLink guys

Explanation:
The decoding of the RF data is usually done by reverse engineering (or “guessing”). So the received data is analyzed and looked for the binary representation of the expected values (“node-id”, “battery value”, “measurement value” etc.).

If you notice the id is changing for negative values, then very likely the id bits are wrongly guessed (the sign bit to indicate negative values is wrongly considered to belong to the device id).
Therefore you see the id changing…

Though you already found a way to circumvent this flaw, it’s better to get this fixed by the RFLink firmware itself

The RFLink mainainers have been quite responsive in the past. If you point them to your findings here and provide useful data, I’d expect them to fix it quick

[vzorglub (Vincent Regaud)]

There have been no update on the RFLink firmware for over a year now…
I am waiting for the next release and then we’ll see

[curlyel]

Well, it’s still alive
Seems, they are quite busy:

https://www.letscontrolit.com/forum/viewtopic.php?f=11&t=5646

Anyway, I’d suggest posting your findings there or get in direct contact to “Stuntteam”

[vzorglub (Vincent Regaud)]

Coolio, will do.

[butteryak]

Hello,
I have RFlink setup and “online” in paper UI. I have my RFlink wired to a NRF24L01 so that I can communicate with Milights.

So far I’ve managed to receive info when I tap a remote.

16:29:02.692 [INFO ] [ig.discovery.internal.PersistentInbox] - Added new thing 'rflink:color:usb0:MiLightv1_14BA_00' to inbox.
16:29:02.694 [INFO ] [smarthome.event.InboxAddedEvent      ] - Discovery Result with UID 'rflink:color:usb0:MiLightv1_14BA_00' has been added.

And they show up in my inbox. So I know hardware is functioning properly.
But if I try to add them as things I get errors.

16:29:49.833 [ERROR] [thome.core.thing.binding.ThingFactory] - Thing factory (class org.openhab.binding.rflink.internal.RfLinkHandlerFactory) returned null on create thing when it reports to support the thing type (rflink:color).

16:29:49.844 [WARN ] [ig.discovery.internal.PersistentInbox] - Cannot create thing. No binding found that supports creating a thing of type rflink:color.

Just not sure where to go from here, I know from the documentation that it says send/receive to milight is possible, but there is not much documentation as to how to accomplish this.

Thanks much.
B

[vzorglub (Vincent Regaud)]

@butteryak

Just not sure where to go from here, I know from the documentation that it says send/receive to milight is possible, but there is not much documentation as to how to accomplish this.

For milights, I gave up with RFLink and I went this way:

EspMilightHub new binding for milight limitlessLED and easybulb

UPDATE: For all OH3 users please update to minimum of 3.1.0 Milestone 1 and the latest binding is merged and built in from now on. Just wanted to let other users of Milight globes know that I have completed a new Binding that allows a single opensource Bridge (bridge created by Chris Mullins aka Sidoh) to automatically find and add Milight globes into OpenHab. The first question Openhab users may have is “Why another binding when one already exists?”, The short answer/s to this is the new OPENS…

Super easy to set-up and works a charm

[butteryak]

yeah, thats they way i’m going too, I have an ESP8266 coming this week. gonna set it up. thought maybe there might be some advantages, specifically, since I have a wired ethernet connection to the Pi->RFlink this would eliminate the need for a bridge, as the RFlink can communicate directly with the lights. I was hoping this would be a more direct way, as apposed to having the bridge as the middle man. Looks like it would be a lot of work to figure out via RFlink/openhab. I only wish there was a wired version of the bridge.
Thanks!
Looking forward to working with the RFlink binding anyway for my 433 devices.

[DirkF]

Hello everybody,
i am looking for a current compiled version of RFLink binding to download.
Could someone provide that?

Thanks in advance

[bfksoql (Piotr Sokolowski)]

Is there a rflink binding version working on openhab 2.4 ?

[cailleute (Martin Mailloux)]

Looking for the best way to use rflink. So, same question: Is there a binding working on Openhab 2.4 ?

[cartemere (Thomas)]

Hello there,

I made some changes on the OpenHab 2 RfLink plugin, and added some functionalities on the Somfy RTS Rollershutter management.
Full description & setup is available on the Github :

Issue: RTS Shutter position tracking

But in a few words :

• RTS Thing mapped on a virtual RfLink remote (internal RfLink rollingcode system) can now track the rollershutter position by measuring time between commands nd then guessing the shutter position (you only need to specify the time taken by the rollershutter to move from closed to opened)
• While moving, the current position of the shutter is displayed (1 update/second)
• You can order the shutter to move to a specific position (like : 80%). the RfLink plugin will then send an order to move the shutter in the right way, and then send a STOP event once the target position is reached.
• You can “link” existing physical remotes ids, so that the RfLink plugin is able to track the shutter moves from external orders (i.e. you can mix existing remotes orders with RfLink orders)

it is for Openhab 2.3 for now, I will try to compile it for OpenHab 2.4
(BTW : are there any changes on this side ?)

[cartemere (Thomas)]

About he 2.4 binding compatibility, I can confirm the RfLink 2.3 “direct” binding (i.e. no MQTT or external scripting) works like a charm on a OpenHab 2.4
(setup : Raspberry Pi 3B+ runnning Raspbian Shelter + Openhab 2.4 installed through Docker)

Installation instructions are available here :

Issue: openhab 2.4 support

PS : last build also include Discovery support for embedded RTS remotes :

Issue: Discovery support for registered RTS remotes