The extact below from the manual describes update that allows a setup of recording devices updates that occur due to MQTT message reception. The new feature is in http://mcsSprinklers.com/mcsMQTT_4_1_8_0.zip
Announcement
Collapse
No announcement yet.
Logging of HS Devices updates from MQTT
Collapse
X
-
Having got some devices setup and responding (thank you for the assistance in another thread) I now want to get logging working.
Homeseer 4, plugin version 5.5.3.4
I followed the guidance;
The device I am testing with is a door with a simple open and closed status. It is reported from my Comfort alarm, read by a python script and recognised by the MQTT broker.
The status changes in Homeseer;
That side of things appears to be working as it should.
I would like to see that status change in the Homeseer log but at the moment I am not getting anything.
Any help or suggestions gratefully received.
-
The logging conditions that are in the plugin is
1. History Enabled (Association tab H column for associated row as in your screenshot)
2. Log enabled (General tab as in your screenshot)
3. Value Changed (MQTT message Payload - was previously not 0 for the case in your screenshot)
So it appears that the HS log should be showing the record of the feature update. In the current plugin debug there should be two lines when the Button feature is being updated and logging logic is applied. They start with the following
"Update Accepted " ... shows general info about the update
"Updating Device from " ... shows the before and after values of the feature
"Button Value " ... shows the prior and current values of the button to assess if change has happened
I added a third to the attached that is executed just before the logging criteria is evaluated. It starts with "SetDeviceValue Log " and shows the values of each of the criteria to do a log. If the above three debug lines do not provide insight for a lack of logging then unzip the attached into \bin\mcsMQTT folder to replace the file of the same name to get additional info.
Attached Files
Comment
-
G'day - I uploaded the DLL you sent and had a look at the log after actioning the device;
04/10/2020 14:13:18 262113 | Update Accepted 386 to 1 StatusType=2 Payload= 1 RegExValue=1
04/10/2020 14:13:18 262115 | Updating Device from 0 PayloadNumeric=True
04/10/2020 14:13:18 262116 | SetDeviceValue Log True History True ValueChange True
04/10/2020 14:13:18 262118 | SetDevcieValueString2 RegEx on 1, Pattern=, Replace=, Match=0, sValue=1 Object reference not set to an instance of an object. 0 Object reference not set to an instance of an object.
386 is the front door I am testing.
I'm guessing the answer may be in the 'not set' message - but as I'm not a programmer I don't know.
Comment
-
You are correct. It was actually a HS3 property that did not get converted to HS4 properly. Corrected in http://mcsSprinklers.com/HSPI_mcsMQTT_5_5_3_7.zip. mcsMQTTHS4_2020.dll into \bin\mcsMQTT is all you need to update
Comment
-
This seems to reflect a scenario where the MQTT Broker sends the messages to mcsMQTT client. If the messages were sent to the broker with the retain flag then each time mcsMQTT reconnects to the broker then the message will be resent to mcsMQTT. This will result in the last change time being updated, assuming the LastChange property is setup to update the time even if the device does not change. This is a MISC setting on the Edit tab. The comfort alarm MQTT client is the one that determines if the retain flag is used or not used.
Could this explain it?
Comment
-
The device I am testing with is a door with a simple open and closed status. It is reported from my Comfort alarm, read by a python script and recognised by the MQTT broker.
Comment
-
Thank you.
As I said earlier I'm not a programmer, just a tinkerer :-)
I have looked at the python script (attached) but don't see anything that appears to be LastChange. Maybe it needs a line to set it to 'off'?
If there is a python expert out there I would be happy to hear suggestions.
comfort2.txt
Comment
-
I am also not a python author, but the script does not appear to have any periodic communications. It does respond to comfort which may initiate a daily status report.
In mcsMQTT, General Tab enable History for perhaps 10 days to save all incoming messages. This will give you the ability to see what messages have been delivered over a multi-day period using the History tab of mcsMQTT. If you get messages that occur at the same time as HS device updates then you know the source is comfort.
Comment
Comment