NULL instead of false in Standard parser Command 05 03

Add-ons Bindings
1

Dear all

Still trying to get ebus binding running. One more observation I made: When trying to integrate telegrams from command 05 03 in order to read out state of flame or pump etc. I get NULL values when all flags are 0 (i.e. byte 8 is 00), i.e. using smarthome:ebus resolve:

F1 FE 05 03 08 01 01 00 FF 2C FF 27 0B 3E AA
^^------------------------------------------ Source address       | Type: Master         | F1
   ^^--------------------------------------- Destination address  | Type: Broadcast      | FE
      ^^ ^^--------------------------------- Command              |                      | 05 03
            ^^------------------------------ Master Data Length   | Length: 8            | 08
               ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^------ Master Data          |                      | 01 01 00 FF 2C FF 27 0B
                                       ^^--- Master CRC           |                      | 3E

Resolve the telegram
********************

Found 1 command method(s) for this telegram.

Values from command 'auto_stroker.op_data_bc2tc_b1' with method 'GET' from collection 'std'
  state_valve2         = NULL
  status_auto_stroker  = 1
  temp_return          = NULL
  temp_outside         = 11
  temp_boiler          = 22
  state_water_flow     = NULL
  state_alarm          = NULL
  state_pump           = NULL
  temp_dhw             = 39
  state_gas_pressure   = NULL
  state_air_pressure   = NULL
  state_flame          = NULL
  state_valve1         = NULL
  performance_burner   = NULL

only when one of the flags is 1, I get for the remaining flags, which are 0 a “false”:

03 FE 05 03 08 01 00 01 FF 2C 16 28 10 C4 AA
^^------------------------------------------ Source address       | Type: Master         | 03
   ^^--------------------------------------- Destination address  | Type: Broadcast      | FE
      ^^ ^^--------------------------------- Command              |                      | 05 03
            ^^------------------------------ Master Data Length   | Length: 8            | 08
               ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^------ Master Data          |                      | 01 00 01 FF 2C 16 28 10
                                       ^^--- Master CRC           |                      | C4

Resolve the telegram
********************

Found 1 command method(s) for this telegram.

Values from command 'auto_stroker.op_data_bc2tc_b1' with method 'GET' from collection 'std'
  state_valve2         = false
  status_auto_stroker  = 0
  temp_return          = 22
  temp_outside         = 16
  temp_boiler          = 22
  state_water_flow     = false
  state_alarm          = false
  state_pump           = false
  temp_dhw             = 40
  state_gas_pressure   = false
  state_air_pressure   = true
  state_flame          = false
  state_valve1         = false
  performance_burner   = NULL

This is a problem since openhab seems to interpret a NULL as an unassigned state of the item and will not do anything with it (e.g. no reaction in a rule on received update when e.g. state pump goes from true to NULL).

Shouldn’t the standard parser programmed in such a way that when byte 8 goes to 00 that all items of that byte (e.g. flame, pump) go to false instead of NULL?

Best regards
Rolf

2

I can’t answer about this binding in particular but a changed trigger should work even when an item goes to NULL.

3

Dear Rich,

Thanks for the reply. my rule looks as follows:

rule "Kesselpumpe"
when
	Item Pump received update
then 
	val c = Pump.state
	logInfo("Kesselpumpe.rules", "ACHTUNG c: {}", c)
	if (c == ON){
		KP.sendCommand(ON)
    }    
	else if (c == OFF){
		KP.sendCommand(OFF)
	}
end

I understand that there is no OFF sent to KP since the state goes to NULL, however in log not even logInfo is shown when Pump.state goes from true to NULL, i.e. I suspect that the received update command is not triggered, when the state goes to NULL.

What do you think? (Btw: the rule may look silly but by doing so, I ensure that KP always have a state ON or OFF)

Best Rolf

4

Try changed instead of received update.

5

Unfortunately did not work either…

6

Dear all, dear Csowada

After some more digging, I found out that when Byte 8 of command 0503 turns to 00 (i.e. all bits/flags are zero), although the log shows me that the states went to NULL:

[DEBUG] [nhab.binding.ebus.handler.EBusHandler] - Key state_pump with value null

this state is somehow not transmitted to the openhab environment, i.e. the “openhab” state of this item stays still in the state it had before the ebus sate of this item went to NULL, as shown in the paper UI:
Pump

Therefore I suspect that the ebus binding somehow does not transmit the NULL state to the openhab environment.

I would highly appreciate some help here.

Best regards
Rolf

7

Hallo @Logos,

I’ve analyzed and corrected the error. You should replace your ebus core library with this snapshot. I have only tested this version against the internal JUnit tests.

https://oss.sonatype.org/content/repositories/snapshots/de/cs-dev/ebus/ebus-core/0.9.18-SNAPSHOT/ebus-core-0.9.18-20180502.084117-10.jar

8

Dear Csowada

It seems to work! Thank you so much.

Best regards
Rolf