[SOLVED] MapDB reinstating Items but actions not taken (via MQTT)

Tags: #<Tag:0x00007f0145f303c0> #<Tag:0x00007f0145f30140> #<Tag:0x00007f0143e4ff98>

(Nikhil Komalan) #1


I am currently running OH2 on RPi3. I have sucessfully used mapdb to reinstate items serialy.

Now currently am controlling state of my LED via MQTT. And last state of LED is stored properly in MapDB. And also on restart, the item value is gettiing reinstated but my “LED” is not turning On.

I have tested the mqtt connection, and its working fine. No issues with mqtt connections.

Here is my Item configuration file having LED switch item:

 Switch	STM32F4_Light_eth	"Led Light (PL8)	"	<light>	{ mqtt=">[mosquitto:/myhouse/light:command:ON:ON],>[mosquitto:/myhouse/light:command:OFF:OFF],<[mosquitto:/myhouse/light/state:state:default" }

I havent added any rules, and in sitemap just displaying the above switch.

Here is my event log file:

6:02:30.061 [WARN ] [del.core.internal.ModelRepositoryImpl] - Configuration model ‘demo.rules’ is either empty or cannot be parsed correctly!
16:17:54.950 [INFO ] [smarthome.event.ItemCommandEvent ] - Item ‘STM32F4_Light_eth’ received command ON
16:17:55.034 [DEBUG] [apdb.internal.MapDBPersistenceService] - store called for STM32F4_Light_eth
16:17:55.068 [INFO ] [smarthome.event.ItemStateChangedEvent] - STM32F4_Light_eth changed from NULL to ON
16:17:55.139 [DEBUG] [apdb.internal.MapDBPersistenceService] - Stored ‘STM32F4_Light_eth’ with state ‘ON’ in mapdb database

As here we can see in log, item gets updated to ON but LED is not turning ON.
Any help is appreciated.

(Vincent Regaud) #2


Couple of bits:

You item configuration can be simplified:

Switch	STM32F4_Light_eth	"Led Light (PL8)	"	<light>	{ mqtt=">[mosquitto:/myhouse/light:command:*:default],<[mosquitto:/myhouse/light/state:state:default" }

Second, when mapdb restores the states on start up, it only updates the state. It doesn’t send a command to the item.
You will need a rule:

rule "restore light"
    STM32F4_Light_eth changed from NULL

You would think that adding an ouput binding on a state change would solve the problem but you would end up with a MQTT loop.