mcsMQTT Plugin

[Michael McSharry]

In some of my recent testing I uncovered that the association table will not appear is a browser window to mcsMQTT page was not open previously. In all my testing I had browser windows open all over the place to test different aspects so I missed this previously.

This has been fixed in 3.2.3.1

[doppiaemme]

Hi Michael,

I was running an old 3.0.7 loaded manually when today I decided to switch to the auto-installer.
The regex replacement was working fine before but now I don't manage to get it working again.
This is what I use:

I would expect to see 48,4 but instead I get 484

Is it me missing something after the upgrade?
thanks

[Michael McSharry]

Fixed in 3.2.5.2

[happnatious1]

Running version 3.2.6.1. plugin is taking up a lot of cpu resources. Homeseer starts out stable, enabling the plugin with no accept or reject check boxes selected yields the first increase. then select disable broker check box and re-start plugin yields second high cpu level.

[Michael McSharry]

I suspect there are many HSEvent callbacks. Can you enable debug from General Tab and collect a minute or two of data that will be in \data\mcsMQTT_Debug.txt. Post it. It would also be useful to have you \Config\mcsMQTT.ini and \data\mcsMQTT.db.

[happnatious1]

Looks like I belong at the excessive cpu thread, I'll move over there.

[qwiksilver96]

Events Not Firing

Michael, I upgraded recently from 3.0.x.x to the newest version in the updated. After updating, some events do not fire. Have you noticed any issues with events not running upon Topic and Message being received. I am running mqtt-spy to verify that the message is reaching the MQTT broker. Strange thing is that some events fire correctly when messages are received. Other do not.

For instance, the first event (MQTT: Electric Blankets - ON 2) does not fire when the referenced topic and message are sent to the broker. However, the 2nd event (MQTT: Electric Blankets - OFF 2) does fire. Strange thing is that the 2nd one would not fire after the update until I recreated it from scratch. Even more bizarre is that when I recreated the first one, it would not fire even though it was also created from scratch. Any ideas?

Best,
Frank

[Michael McSharry]

Much has happened between 3.0 and 3.2. Provisions exists for upward compatibility, but this is a big jump. The most likely situation is that the Device Reference has changed. If you post your \Data\mcsMQTT\mcsMQTT.db then I will be better able to diagnose.

[qwiksilver96]

File is attached

Thank you Michael

[Michael McSharry]

The good news is that the database has migrated properly to the current versions.

I see ha/Electric Blanket to have published "1". This should have triggered the event. I can try to reproduce, but it would be easier to me if you had debug enabled and the file \Data\mcsMQTT\mcsMQTT_Debug.txt was collecting data when this message was published. Most of the recent work with mcsMQTT has been with devices and not much attention has been given to Events, but that also means the events should not have been affected.

This particular topic has not been associated with a HS device. It does not need to be, but just pointing it out.

[qwiksilver96]

The good news is that the database has migrated properly to the current versions.

I see ha/Electric Blanket to have published "1". This should have triggered the event. I can try to reproduce, but it would be easier to me if you had debug enabled and the file \Data\mcsMQTT\mcsMQTT_Debug.txt was collecting data when this message was published. Most of the recent work with mcsMQTT has been with devices and not much attention has been given to Events, but that also means the events should not have been affected.

This particular topic has not been associated with a HS device. It does not need to be, but just pointing it out.

File is attached.

I sent the topic and message several times but there appears to be no trace of the event running in the debug file.

[Michael McSharry]

I added debug every step of the way in the attached. Unzip into our HS folder and try again. Of course keep debug enabled.

[qwiksilver96]

I added debug every step of the way in the attached. Unzip into our HS folder and try again. Of course keep debug enabled.

New file attached.

[Michael McSharry]

4/8/2018 11:15:37 PM Payload = 0 causes the event to trigger.
4/8/2018 11:15:45 PM Payload = 1 does not match the trigger event that is looking for Payload = 0

I can see now that an optimization that I did was to keep a dictionary of Topics vs. triggers and since you have two events with the same topic, but different payloads the assumptions I made about this optimization is not valid. I need to rework it. Likely tomorrow for a solution.

It is great that you can provide this input so quickly so it can be resolved. Note that the normal approach used is to associate the topic with a HS device and then trigger based upon the HS device with a specific payload. Either way should work, but just letting you know. The device approach lets you see the status of the topic in a HS device.

4/8/2018 11:15:37 PM	63373	| ActoOnMessageFor Trigger Topic ha/ElectricBlankets,Payload=0  
4/8/2018 11:15:37 PM	63373	| Topic Found as Trigger=True, Trigger Payload = 0  
4/8/2018 11:15:37 PM	63373	| Trig

gered=True  
4/8/2018 11:15:37 PM	63374	| TriggerFire ha/ElectricBlankets=0  
4/8/2018 11:15:37 PM	63374	| ReceiveTriggerTrigFromInfo ID=1406, Topic=ha/ElectricBlankets  
4/8/2018 11:15:37 PM	63374	| ReceiveTriggerGeteTrig ID=1406, Topic=ha/ElectricBlankets  

4/8/2018 11:15:37 PM	63436	| ActoOnMessageFor Trigger Topic ha/STATUS/ElectricBlankets,Payload=0  
4/8/2018 11:15:37 PM	63468	| HSEvent Do= False VALUE_CHANGE for Device 247  
4/8/2018 11:15:38 PM	64755	| HSEvent Do= False VALUE_CHANGE for Device 51  
4/8/2018 11:15:45 PM	71901	| ActoOnMessageFor Trigger Topic ha/ElectricBlankets,Payload=1  
4/8/2018 11:15:45 PM	71902	| Topic Found as Trigger=True, Trigger Payload = 0  
4/8/2018 11:15:45 PM	71902	| Triggered=False

[Michael McSharry]

Please confirm that the attached solves the issue.