MQTT Received & not Accepted by mcsMQTT

[peterpc]

Yesterday I have added a door/window sensor and was working ok.
Today the device for open/close is not updated anymore.
It is a Zigbee device.
I see the commands in zigbee2mqtt.
I see the communication in the broker.
I see in the statistics tab MQTT Received & not Accepted by mcsMQTT counting up when sensor is triggered.
How can I make mcsMQTT accept the commands and update the device again?

[Michael McSharry]

The Association tab for this door/window sensor should have the "A" checkbox checked to map it into a HS device.
The Control/Status UI type (on Edit tab) will determine what property in HS is updated when the topic is received. I'm guessing that the topic has a payload of "close" or "open". This means that the Control/Status UI should be a button and the Value Status Pairs (VSP) should have entries of 0 for "close" and 1 for "open". The same VSP relationship should be visible in the HS device Device Management / StatusGraphics tab. mcsMQTT will store 0 or 1 in the HS DeviceValue when it receives "close" or "open".

The Association tab row for this topic will also update the Payload column so that should be updating independent of the HS device. If statistics are updating as not-accepted then it implies that the "A" column checkbox is not set for whatever topic is received and counts being updated. If it is checked then you can remove the association and then recreate it by unchecking the "A" checkbox and checking it again. This will delete and create a new HS device. The question is then why this step was needed. I can look deeper with the debug/config files described below if that would help.

If you have History enabled from the General tab, say for 1 day for all topics, then the History tab will show the topics & payloads that mcsMQTT is actually seeing. This same info will be contained in the debug described in the next paragraph.

The General tab has a debug option at the top. The data goes into \Data\mcsMQTT folder as a .txt file. If you collect some data I will have better visibility. In the same folder is the .db file that contains the setup information for topics and HS associations. That will allow me to replicate your setup for better visibility. They can be emailed to mcsSolutions at CenturyTel dot net.

[peterpc]

The Association tab for this door/window sensor should have the "A" checkbox checked to map it into a HS device.
The Control/Status UI type (on Edit tab) will determine what property in HS is updated when the topic is received. I'm guessing that the topic has a payload of "close" or "open". This means that the Control/Status UI should be a button and the Value Status Pairs (VSP) should have entries of 0 for "close" and 1 for "open". The same VSP relationship should be visible in the HS device Device Management / StatusGraphics tab. mcsMQTT will store 0 or 1 in the HS DeviceValue when it receives "close" or "open".

The A checkbox is set and control status is a button. Device has Value pairs 0 and 1.

The Association tab row for this topic will also update the Payload column so that should be updating independent of the HS device. If statistics are updating as not-accepted then it implies that the "A" column checkbox is not set for whatever topic is received and counts being updated. If it is checked then you can remove the association and then recreate it by unchecking the "A" checkbox and checking it again. This will delete and create a new HS device. The question is then why this step was needed. I can look deeper with the debug/config files described below if that would help.

A is set, but payload and last date are not updated, date is at yesterday 17:38:23. uncheck and check A does not help

If you have History enabled from the General tab, say for 1 day for all topics, then the History tab will show the topics & payloads that mcsMQTT is actually seeing. This same info will be contained in the debug described in the next paragraph.

I have history set and history is updated on device changes:

0	S	2020-03-26 21:08:43	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":76,"contact": fal se}
1	S	2020-03-26 20:08:21	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":73,"contact": fal se}
2	S	2020-03-26 19:08:01	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":70,"contact": fal se}
3	S	2020-03-26 18:07:42	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":65,"contact": fal se}
4	S	2020-03-26 17:33:48	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":63,"contact": fal se}
5	S	2020-03-26 17:09:52	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":55,"contact": tru e}
6	S	2020-03-26 17:09:44	zigbee2mqtt/0x00158d0003cf497a	{"battery":100,"voltage":3025,"linkquality":70,"contact": fal se}

The General tab has a debug option at the top. The data goes into \Data\mcsMQTT folder as a .txt file. If you collect some data I will have better visibility. In the same folder is the .db file that contains the setup information for topics and HS associations. That will allow me to replicate your setup for better visibility. They can be emailed to mcsSolutions at CenturyTel dot net.

I have emailed you the files.
I had some devices working that I installed months ago and they are still working.
All the devices I installed yesterday did work yesterday, but now not anymore.
They are all "not accepted."

[Michael McSharry]

I isolated the issue to a recent update that created a new database field "ElevateKeys" but was created as an integer and not a text field. I want to recreate the field as the correct type but need to do a little research on how to accomplish it and then not do it again after it has been done correctly. I will provide an update later today.

[Michael McSharry]

The update is at http://mcsSprinkers.com/mcsMQTT_5_2_1_5.zip where the primary file that changed is mcsMQT_2020.dll which goes into \bin\mcsMQTT. I also submitted to updater.

When the plugin starts it will detect if an incorrect database exists. If it does it will copy the data to a correctly formed on. This means it will be a minute of so on the first startup. On subsequent starts the additional delay will not be present.

[peterpc]

Link is http://mcssprinklers.com/mcsMQTT_5_2_1_5.zip
(l was missing)
Up and running again.
Thanks!