RFXCOM Binding: additional NOVY subtype for fan

Add-ons Bindings
1

Hi, I would like to control my Novy kitchen hood with openhab.
This is possible in via Rfxcom.
Novy is available in rfxmgr.exe as a Fan subtype, but the OH3 binding only seem to support 3 Fan subtypes. The Novy one is missing.
Is there a workaround, solution available? How can we make the additional subtypes (similar as in rfxmgr.exe) available?

2

If you’re happy editing the code, you can add it here:

Otherwise post the output from rfxmngr and I’ll try and add it.

3

I’ve been working on this binding recently and the fan details are all in the RFXCom SDK, so I’ve given it a go.

PR here: [rfxcom] Add Novy extractor fans by Jamstah · Pull Request #10891 · openhab/openhab-addons · GitHub

jar to test here: Dropbox - org.openhab.binding.rfxcom-3.1.0-SNAPSHOT.jar - Simplify your life

4

Thanks for your prompt reply Jamstah.
I will test this asap. (might take me a couple of days)

1 Like
5

Hello,

I was able to add the Novy Fan as a new thing, but no luck so far.
I see the rfxcom message being send and acknowledged, but nothing happens.
Maybe I have the wrong deviceid?

Output from rfxmgnr:

================================================
23/06/2021 06:47:51:779= Fan command: 08 17 0B 11 00 00 00 04 00 
================================================
Packettype    = Fan
subtype       = Novy
Sequence nbr  = 17
ID            = 1
Command       = Light
Signal level  = +10 dBm
------------------------------------------------
23/06/2021 06:47:52:029= 0402011100
Packettype        = Receiver/Transmitter Message
subtype           = Transmitter Response
Sequence nbr      = 17
response          = ACK, data correct transmitted
================================================
23/06/2021 06:47:55:196= Fan command: 08 17 0B 12 00 00 00 04 00 
================================================
Packettype    = Fan
subtype       = Novy
Sequence nbr  = 18
ID            = 1
Command       = Light
Signal level  = +10 dBm
------------------------------------------------
23/06/2021 06:47:55:462= 0402011200
Packettype        = Receiver/Transmitter Message
subtype           = Transmitter Response
Sequence nbr      = 18
response          = ACK, data correct transmitted

In openhab I converted 08170B to Decimal 530187 for the deviceid

openhab log output:

07:19:28.920 [INFO ] [openhab.event.ItemCommandEvent       ] - Item 'NovyCmd' received command LIGHT
07:19:28.921 [INFO ] [openhab.event.ItemStatePredictedEvent] - Item 'NovyCmd' predicted to become LIGHT
07:19:28.930 [DEBUG] [rfxcom.internal.handler.RFXComHandler] - Received channel: rfxcom:fan_novy:rfxrpi1:novy:commandString, command: LIGHT
07:19:28.932 [DEBUG] [.internal.handler.RFXComBridgeHandler] - Transmitting message 'Raw data = unknown, Packet type = FAN, Seq number = 0'
07:19:28.934 [TRACE] [internal.connector.RFXComTcpConnector] - Send data (len=9): 08170B0008170B0400
07:19:29.117 [TRACE] [internal.connector.RFXComStreamReader] - Message length is 4 bytes
07:19:29.119 [TRACE] [internal.connector.RFXComStreamReader] - Waiting remaining 4 bytes from the message
07:19:29.120 [TRACE] [internal.connector.RFXComStreamReader] - Received 4 bytes from the message
07:19:29.121 [DEBUG] [.internal.handler.RFXComBridgeHandler] - Message received: Raw data = 0402010000, Packet type = TRANSMITTER_MESSAGE, Seq number = 0, Sub type = RESPONSE, Response = ACK
07:19:29.123 [DEBUG] [.internal.handler.RFXComBridgeHandler] - Transmitter response received: Raw data = 0402010000, Packet type = TRANSMITTER_MESSAGE, Seq number = 0, Sub type = RESPONSE, Response = ACK

I do see a difference in the send data:

rfxmgr:  08170B110000000400 
openhab: 08170B0008170B0400

The 4th octet in rfxmgr ( 08170B11) is the sequence nr (17) in hex
I don’t know how or where the “ID = 1” is being used.
And why is the deviceid being send twice in the openhab command string?

08170B    00         08170B   0400
deviceid  sequencenr deviceid command
6

The first byte is the message length (08), the second is the device type (17 = fan), the third byte is the sub type (0b = novy). The fourth byte is the sequence, it just counts up, not sure if the device will care. The next three bytes are the I’d. I expect novy use 0 to mean 1, 1 to mean 2, and so on. Try 0 as your device I’d.

The next byte (04) is the command. 04=light.

7

Thanks for explaining the byte sequence and their meaning. Makes more sense now :slight_smile:
It works like a charm!
Device id must be 0 indeed.

FYI about the openhab channels:

  • Command String > works fine
  • Globalspeed control (fanspeed) > UP & DOWN are fine, but command STOP throws an error
  • Command (fanlight) > Does not work, command ON & OFF are throwing errors
  • Signal Strenght > Does nothing

I believe this is normal, since NOVY on rfxcom does not recognize the ON, OFF, STOP commands.
For me personally this is fine, since I will only use the Command String channel.

Great work Jamstah!

Thanks a lot.

8

Update:

I just discovered the update in the binding README.md :blush:
So forget my previous comments.

#### fan_novy - Novy extractor fan

A Novy extractor fan.

##### Channels

| Name         | Channel Type                        | Item Type     | Remarks                  |
|--------------|-------------------------------------|---------------|--------------------------|
| command      | [command](#channels)                | Switch        |                          |
| commandString| [commandString](#channels)          | String        | Options: POWER, UP, DOWN, LIGHT, LEARN, RESET_FILTER |
| fanSpeed     | [fanspeedcontrol](#channels)        | RollerShutter | Options: UP / DOWN       |
| fanLight     | [fanlight](#channels)               | Switch        |                          |
| signalLevel  | [system.signal-strength](#channels) | Number        |                          |
9

Great, I’ll get the pr merged.

We could potentially fake a STOP command by sending DOWN 5 times or something. Might be better to do that in a rule than in the binding though :slight_smile:

1 Like
10

Would you be so kind as to share the .things .items and .rules file? I had my rfxcom working in OH2, but since my migration to OH3 (and my new Novy hood) I don’t seem to get it working with the new things/channels/items structure. I can use the fanSpeed controller, but I don’t know how to use the commandString as you write…

Thank you so much!

11

Hi!

Thank you all for the effort you made on the development! I am now also happy to announce that it works perfectly. Anyone working on their own setup, after struggling with the items/sitemap files my setup is as follows:

.items file:
Switch NovyHood “Novy Hood control” {channel=“rfxcom:fan_novy:usb0:0071747a8f:commandString”}

.sitemap file:
Switch item=RFXCOMFanDeviceNovyExtractorFan_CommandString label=“Novy hood selection” mappings=[“LIGHT”=“LIGHT”, “UP”=“UP”, “DOWN”=“DOWN”, “POWER”=“POWER”]

(I chose not to include the other commands in my sitemap to prevent incorrect use)

I will continue now to integrate this with Alexa, when I succeed I will share the information here :slight_smile:

12

Sorry for the late reply Marcel.
Glad to read you were able to work it out.

13

Hi,

Was wondering whether someone could provide guidance to adding the mood mode for the Novy Fan - it is supported in the current FW of the RFXCOM. (see below) .

Have not modified bindings (also no real experience with Java)

27/01/2023 10:05:51:706= Fan command: 08 17 0B 03 00 00 00 07 00 00 00 00 00 00 00 00 00 00

Packettype = Fan2
subtype = Novy
Sequence nbr = 3
ID = 1
Command = Mood mode
Signal level = +10 dBm

27/01/2023 10:05:51:914= 0402010000
Packettype = Receiver/Transmitter Message
subtype = Transmitter Response
Sequence nbr = 0
response = ACK, data correct transmitted

14

Managed to get it done - submitted pull request