Error Message in HS3 Log

[jim@beersman.com]

I'm seeing the following message in the HS3 log when I start the mcsMQTT Plug-In. Just upgraded to the latest version 6.0.13.0

It's not flagged as an error but of type mcsMQTT


ProcessMessage New shellies/shellydw2-E8DB84D4A699/sensor/act_reasons=["poweron"] at Microsoft.VisualBasic.CompilerServices.Symbols.Container.Get Members(String& MemberName, Boolean ReportErrors) at Microsoft.VisualBasic.CompilerServices.NewLateBinding.Object LateGet(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack) at Microsoft.VisualBasic.CompilerServices.NewLateBinding.LateGe t(Object Instance, Type Type, String MemberName, Object[] Arguments, String[] ArgumentNames, Type[] TypeArguments, Boolean[] CopyBack) at MCSMQTT_2020.ProcessMessage.GetJSONArrayKeyList(String sValue) in C:\Users\Public\Documents\LaptopVM\MCSMQTT_2020\ProcessMessa ge.vb:line 732 at MCSMQTT_2020.ProcessMessage.GetPayloadList(String sValue) in C:\Users\Public\Documents\LaptopVM\MCSMQTT_2020\ProcessMessa ge.vb:line 705 at MCSMQTT_2020.ProcessMessage..ctor(MqttApplicationMessage eventArg, Int32 iPubBroker) in C:\Users\Public\Documents\LaptopVM\MCSMQTT_2020\ProcessMessa ge.vb:line 161 Line 0 Public member 'Type' on type 'String' not found.

[Michael McSharry]

The problem is that "shellies/shellydw2-E8DB84D4A699/sensor/act_reasons=["poweron"]" has a payload that starts with "[" so mcsMQTT believes it to be a JSON array and hands it over to Newtonsoft to parse. Newtonsoft flags it as not being valid JSON as reflected in the error message. I will figure out what to do about this.

As a note I do have this same problem with a test case in my Shelly simulation but did not recognize the error that was being generated during my testing.

I believe this message came as a result of Shelly adding an action capability that would operate much like a webhook to overcome the problems of using HTTP/REST with battery powered devices that would go to sleep. It became hit and miss when using REST to poll a device that was asleep to happen to catch it when it awakened. I suspect that they just put the same data used in the webhook for MQTT and did not go the extra step to format it as JSON as documented in their API.

[Michael McSharry]

Should be taken care of in 6.1.0.1 with links at https://forums.homeseer.com/forum/hs...ge-log-hs4-hs3