Log File full of conversion errors - Encode payload template doesn't seem to work

[Michael McSharry]

For the STAT and INFO related issue I suspect you have the Echo enabled on the General Tab. This will result in an endless loop unless you break the loop somewhere else. By adding prefix it changes the topic and the loop is broken. The debug file will contain more info. You can also view the Statistics tab to see the counts for messages during the 30 seconds.

[jrhubott]

I removed the $$STRING: template and that removed the double messages. I was only using it for one device and I can live without it for now.

I was getting double message from a lot of devices and didn't notice till now, it is not just the AmbientWeather plugin but several other plugin driven devices I was publishing. I the long run it would be nice to use the $$STRING template without getting double messages. Could you not just use the DeviceString change only when the Template contains a $$STRING or offer a check box like the older and no longer supported MQTT plugin used. I'm converting to yours from that one and it didn't generate the double messages you just clicked Value or String or Both for the change notification.

Any idea on how to turn off the STAT and INFO? I used them to enable both plugin's at the same time and now I just want to disable the old plugin, remove the STAT/INFO and all my logic works like before.

I think maybe the devices that are somehow publishing without a topic are the problem when I disable the STAT/INFO.

Thanks again for looking into this.
Jason

[jrhubott]

For the STAT and INFO related issue I suspect you have the Echo enabled on the General Tab. This will result in an endless loop unless you break the loop somewhere else. By adding prefix it changes the topic and the loop is broken. The debug file will contain more info. You can also view the Statistics tab to see the counts for messages during the 30 seconds.

Another thing I observed is that the screenshots are pink which indicate that devices are setup for subscriptions. If you are publishing AmbientWeather device changes then the setup should be for non-plugin devices. If you publish and subscribe to the same topic then this is a loop condition too.

I don't understand how to setup the device as non-plugin I guess. I have just been clicking on the A and adding a publish message topic and leaving the subscribed topic blank:




I thought the green was subscribed like this:



I also don't have the echo turned on.

[jrhubott]

Here is an example of a publish occurring without anything set-up.

[Michael McSharry]

My mistake about the pink coloration. Your setup looks fine for the device. On your screenshot of 617 payload I think your HS ref is 3465 and that is not one of the devices associated in mcsMQTT. Do you have multiple devices with the same name?

I can accommodate for $$STRING.

The debug file should provide insight to what is happening related to STAT and INFO. It seems that there is a loop situation for some reason.

On your last post the device changing is 4557. How is device 4557 related to mcsMQTT? Same type question as 617 payload.

[jrhubott]

4560 is the device I sent in the screenshot. It is the top device in the debuglog. I agree it is not associated with mcsMQTT for either 4560 or 3465. But for some reason they are being published as seen in your logs. This is happening for about 10+ devices and these are the ones that have just a STAT/ topic. I don't understand what is going on.

[jrhubott]

I attached my DB and debug log maybe something is wrong in it.

[jrhubott]

Looking through your logs I see a lot of

AddToMQTTSend1 {deviceRef} , inDict = False

when the plugin starts. Many of the deviceRef's are for devices that I don't have setup to publish. I double checked several of them. I don't know if this is causing some of the problem or not.

Jason

[Michael McSharry]

I see the issue I introduced when I added the ability to save HS device changes to the mcsMQTT history database to support charting. This was to allow users the charting ability of mcsMQTT for devices that were not published. I will take care of this. I am not certain yet of implications such as the loop, but as I get through it I will learn more. I'm also adding the user selection for type of event change that will trigger a publish.

[Michael McSharry]

The Edit tab/popup now contains a HS Event row to identify which event will result in a message being published. Default is DeviceValue. No longer use the $$STRING: criteria and each callback is filtered through the new checkbox settings. Check out the attached to see if it has any effect on the STAT and INFO behavior. If it does not then post the debug.

[Michael McSharry]

Forgot attachment.

[jrhubott]

Works great. It appears to have solved all of my problems.

I will keep testing.

Thanks,
Jason