empty command_responses on inject node

[andrei-v1]

Hi, when try to inject status request with inject node ( ex. *#1*32## - check status of 3.2 light)
in debug I see next thing:

{"command_sent":["*#1*32##"],"command_responses":[]}
so command_response is empty

but in same time if I connect monitoring node, I see that BUS responses (*1*0*32## - says it OFF) about status when I asked for it:

[FredBlo]

Hi @akalikin1 ,

Such request should indeed receive a response.
When implementing the connector, I noticed quite many (I mean MANY) differences in how the system reacted based on the gateway I used to connect to the BUS. Some BTicino documented commands did not react as they should, or were even not recognized at all.
However, I did not notice such differences (on the gateways I tested) for lights & shutters (for which requests are actually quite basic in comparison to others).

Which gateway are you using actually ?

[andrei-v1]

I use MH201

[FredBlo]

Hi @akalikin1,

I am not aware of any limitation on MH201, but I have none to test this :-(
Is the firmware version of your gateway the latest one available because I saw quite many such flaws corrected after a firmware update...

[andrei-v1]

Is the firmware version of your gateway the latest one available

Hi, updated to the last firmware, but issue still persists

[andrei-v1]

Just to clarify...
if I connect monitoring node, I see that BUS responses *1*0*32## when I inject *#1*32## command.
So I suppose the problem is just with "command_responses":[] buffer of inject node

[FredBlo]

Hi @akalikin1 ,

When responses are empty, it does not mean 'nothing' was sent to the BUS nor that the command was not received (acknowledged), but only that the gateway did not send any response to the command sent...

I will try to explain how it works :
The way Bticino implemented its gateway works in 2 different modes :

• either you send a command, the gateway processes it. Sometimes (based on command type), you receive a response to your single command. These are session-calls (i.e. a session is opened with the gateway, command is sent, responses are received (if any), gateway confirms all is done, session is closed)
• either you monitor all info passing on the BUS. This is a single event session which remains open all the time.

The nodes I built manage both.
When you inject a command (using the inject node, or using any other node, such as light for example), if a response is received, the 'payload' is updated so you can further process it (if needed).
On the other hand, when you inject a command, some info will also be generated on the BUS. And this info is fetched when monitoring (using the monitoring node, or using another node such as a light for example).
There is no technical mean to make a link between a command sent (session call) and something read on the BUS while monitoring (event session). Said differently : when the command *1*0*32## is read on the BUS, all we know is that light point 3.2 is OFF (we do not know whether this was sent based on a command to discover current state, or that this is a command sent as is (by an external gateway command or using an internal BUS button) to turn it off...

In your case, when you inject *#1*32## :

• command is sent and should receive the response *1*0*32##
• on the BUS, *1*0*32## should also be sent
  At least it is how it is officially documented by Bticino (and also how it reacts on the gateway I tested (MH202, F455, F459 and myHomeServer1)) :
  
  MH201 seems to manage the monitoring but not the response for such light commands :-(

I do not know exactly what you want to achieve, but you could use a light node to ask for state and connect its output to fetch state, discarding the initial state request which does not contain the response (state). The sole limitation of this method is that the output containing light state will be another payload (which can be a constraint if you need other info stored on the initial payload...)

Sample flow :

[{"id":"bf5e40a97ff12161","type":"myhome-light","z":"d6f1adbb.0c574","name":"Lightpoint 3.2","buslevel":"private_riser","lightid":"32","isgroup":false,"topic":"switch","gateway":"a4e23617.d0c288","smartfilter":false,"skipevents":false,"isstatusrequest":false,"output2_name":"","output2_type":"boolean","x":814,"y":832,"wires":[["35fc7742cf76c72e"],[]]},{"id":"05d6ebf3d58f746a","type":"inject","z":"d6f1adbb.0c574","name":"Ask for state","props":[{"p":"topic","vt":"str"}],"repeat":"","crontab":"","once":false,"onceDelay":0.1,"topic":"state/switch","x":624,"y":832,"wires":[["bf5e40a97ff12161"]]},{"id":"35fc7742cf76c72e","type":"switch","z":"d6f1adbb.0c574","name":"Discard initial command sent","property":"payload.command_sent","propertyType":"msg","rules":[{"t":"null"},{"t":"else"}],"checkall":"true","repair":false,"outputs":2,"x":1054,"y":832,"wires":[["7113902e594d3958"],["58f4842519d02e1e"]]},{"id":"7113902e594d3958","type":"debug","z":"d6f1adbb.0c574","name":"is state 'response'","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1304,"y":812,"wires":[]},{"id":"58f4842519d02e1e","type":"debug","z":"d6f1adbb.0c574","name":"is state 'request'","active":true,"tosidebar":true,"console":false,"tostatus":false,"complete":"payload","targetType":"msg","statusVal":"","statusType":"auto","x":1294,"y":852,"wires":[]},{"id":"a4e23617.d0c288","type":"myhome-gateway","name":"F-455","host":"192.168.0.210","port":"20000","pass":"12345","timeout":"600","log_in_lights":false,"log_in_shutters":false,"log_in_temperature":false,"log_in_scenario":false,"log_in_energy":false,"log_in_others":false,"log_out_cmd":false}]

Note : node is called in state mode (.topic = state/..) and you must disable smart filtering on node in this case

Hope it helps...

[andrei-v1]

Thanks for response.
Seams there is some problem with MH201 exactly

[FredBlo]

OK, interested to see if / what they respond...