OpenWebNet lights command translation (What=1000) not working ?
Hi,
I am building a connector which is using a myHome gateway to monitor all BUS events and allow sending commands to it (running on ‘node-RED‘, more info here if wanted : https://flows.nodered.org/node/node-red-contrib-myhome-bticino-v2).
I have a question / issue about the way lights commands are sent / received.
If I turn a lamp ‘ON’ (let’s take A=5/PL=8 as sample), I send the command ‘*1*1*58##’ on the BUS.
While monitoring the BUS, I will see this frame twice :
– a first time when command is sent
– a second time when actuator changed its state and responds with its new resulting state
When using my physical buttons, I see it is made differently.
The command sent is ‘*1*1000#1*58##’
And the actuator responds with its new light state with ‘*1*1*58##’
Which makes it possible to make a difference, when analyzing a frame, between a state change request and an effective state change result.
And I guess this is what this translation is supposed to be used for.
This corresponds with what’s described in the OpenWebNet documentation as ‘Command translation – What = 1000’.
‘WHAT’ is documented as ‘It accepts a parameter that is the value of what table […] also for dimmers’.
However, when sending such commands on the BUS through the gateway, I receive a NACK as answer… (the command is not sent on the BUS at all).
I tried with multiple gateways -those I have available on my BUS to test- : MH202, F455*, F459 and myHomeServer1.
*The sole which does accept some is the ‘F455’ : basic ON/OFF calls are accepted but it fails when sending dimmer functions (such as *1*1000#2*58## to dim 20%, or *1*1000#30*58## to dim up,..).
My question : how is this command translation supposed to work ? Is this a bug accross all/most gateways ?
Or is there a valid way to send a command using the gateway which can be differenciated from state change result itself ?
<div id=”ConnectiveDocSignExtentionInstalled” data-extension-version=”1.0.4″>Thanks in advance !</div>
You must be logged in to reply to this topic.