krambriw wrote:
I think the above is correct since the code is written in such a way that it by default will block repeated events (I think in this case during 1 second). You can see that you received one event each for '02', '03', '04' and '05' which is what I expected. Maybe this is what is causing the problem for you.
For sure this kind of 'prevent auto-repeat' feature is causing my problem: my initial issue happened when triggering twice same MQTT message. In our current test script the '02', '03' are indeed the seconds of the time when message is sent so we clearly see event only occurs when seconds have changed.
Could there be an additional tick box to tell the plugin not to discard repeated messages or a configurable 'non-repeat time' where setting this parameter to 0 would disable this feature?
Because this is what I need as I have implemented a cancellation behaviour using zwave: when user pushes a switch, a zwave scene command is received by openHAB and forwarded to Eg as a MQTT message. The scene command activates a certain 'house mode' and user is notified by TTS. If he wants to cancel his action, he just needs to push the switch again. Currently, this means that the 2nd push will be discarded as it does not generate a 2nd identical event in Eg.
From my short experience with MQTT, message sending on a LAN is reliable even with a QoS set to 0 so this kind of 'prevent auto-repeat' does not sound necesary.
krambriw wrote:
Also worth mentioning is that the MQTT Client is not written to support any kind of message formats by default so it could be we would have to add some specific section for messages coming from openhab.
Personally I am using Python scripts which makes it easy to interpret the MQTT.* events but other Eg users may be interested in this. OpenHAB handles MQTT in 2 ways:
1) an event bus binding which basically translates all in/out messages from opnHAB bus to MQTT messages. This is configured in the global OpenHAB configuration file so the topic can be customized and the documentation suggests:
mqtt-eventbus:broker=m2m-eclipse
mqtt-eventbus:commandPublishTopic=/openHAB/out/${item}/command
mqtt-eventbus:stateSubscribeTopic=/openHAB/in/${item}/state
where item is the name of the item (=device) and the content of the message is the state/command received/sent
This is my setup as I only use openHAB for interfacing to zwave and its clean and fast Web UI: all the 'intelligence' of automation is in Eg.
2) per item binding: any item (=device) can be configured in a way it generates an MQTT message (command message) or is updates through a MQTT message (state message): so again the topic is fully configurable
krambriw wrote:
Could you add the following print statements / modify your code and see what results we get printed when you receive messages from openhab?
Here is the log of same test with additional output :
15:45:54 <paho.mqtt.client.Client object at 0x04756FB0> None 54
15:45:54 self.eventCollection[res_key]=
15:45:54 res_base= ['54']
15:45:54 bDelay= True delay= 5.0
15:45:54 res_key= /openHAB/in/AV_mRDC_Salon_media_album/state, 54
15:45:54 res_base= ['54']
15:45:54 MQTT./openHAB/in/AV_mRDC_Salon_media_album/state u"54"
15:45:57 <paho.mqtt.client.Client object at 0x04756FB0> None 57
15:45:57 self.eventCollection[res_key]=
15:45:57 res_base= ['57']
15:45:57 bDelay= True delay= 5.0
15:45:57 res_key= /openHAB/in/AV_mRDC_Salon_media_album/state, 57
15:45:57 res_base= ['57']
15:45:57 MQTT./openHAB/in/AV_mRDC_Salon_media_album/state u"57"
15:45:57 <paho.mqtt.client.Client object at 0x04756FB0> None 57
15:45:57 self.eventCollection[res_key]= ['57']
15:45:57 res_base= ['57']
15:45:57 bDelay= True delay= 5.0
15:45:57 res_key= /openHAB/in/AV_mRDC_Salon_media_album/state, 57
15:45:57 res_base= ['57']
Indeed I am happy we found the reason of that strange behaviour!
Now I have to investigate the connect/disconnect every 20 secs of your Paho based plugin on my home automation PC. But this should be software or hardware related as it did not happen on other computers where I tested your plugin on.
. They are both running Win10...