BLEMQTT beacons- HS values changes

[wpiman]

So I have BLEMQTT running on a Raspberry pi and it is reporting to my MQTT broker on a server in my network . MCSMQTT (HS4- latest version) points to the same broker and I added the beacons. I set the beacons to store zero when in range. I set the timeout to 90 (the pic has it at ten but I have updated it)



The issue is the values of the beacons in range keep changing. I just have an event that fires endlessly when the value changes, and in the GUI-- I see the image flip flop between green (value zero), and then the back to the black gear. This seems to happen whenever I see that particular beacon report when I look at mosqutio_sub.




Any ideas?

[Michael McSharry]

I see the image flip flop between green (value zero), and then the back to the black gear.

The images should be green or red for the two states.

I just have an event that fires endlessly when the value changes

If mcsMQTT is working properly then it will only change the DeviceValue once at the 90 second interval.

What seems to be happening is the DeviceValue is being updated on each beacon message with the RSSI which has a value that is not the value of the red or green icon. I will take a look.

[wpiman]

The images should be green or red for the two states.



If mcsMQTT is working properly then it will only change the DeviceValue once at the 90 second interval.

What seems to be happening is the DeviceValue is being updated on each beacon message with the RSSI which has a value that is not the value of the red or green icon. I will take a look.

Yes. Bear in mind a run BLEMQTT on a seperate RPI and have a seperate broker. Should be fine but I don't think that is the typical setup.

Let me know if any logs would be useful.

[Michael McSharry]

I ran a test and discovered that the HS4 plugin Local page had Bluetooth setup on both the Bluetoth tab and the top of the IR/RF tab and the radio selections were not visible on the Bluetooth tab display. This is only cosmetic and did not affect operation.

What I suspect is that the beacon topic was accepted on the Association tab before the change on the Local page was made to not storing RSSI. The local page text needs to be changed to indicated that it is a default. The actual setting for this is near the bottom of the Edit tab. This was done so that some beacons could be home/away and some could be RSSI. I forget about this.

What still does not make sense is the gear icon. It means that you have RSSI values of under -126 db. I guess a receiver could be more sensitive and receive very low signals. Perhaps I should increase the valid range beyond -126 db. What type of values are you getting for RSSI that show as gears. I do not see the value displayed on your screenshot.

[wpiman]

I noticed the that the Bluetooth selections were in both places as well. I cannot change them in the RF section-- but the values don't seem to stick in the Bluetooth area.

I removed the Beacons- redid the selections and readded them. Same behavior.

I added the Beacons to a plugin I have called device monitor. I mapped the values coming in over time below. It seems like some of the RSSI values are getting set-- and then it goes back to zero. I think that explains why the images are wrong-- the device values are going to the RSSI at times.

[Michael McSharry]

I do not see any screenshots of where you changed the HS Device reporting to be present/not present vs. RSSI on the Edit tab of mcsMQTT. There are later versions of mcsMQTT posted todayh that have the Bluetooth tab fixed so duplicates do not exist. Current is 5.19.2.4.

[wpiman]

from my phone. Hope it shows up ok

[Michael McSharry]

[quote]
I think that explains why the images are wrong-- the device values are going to the RSSI at times.
/quote]

The icon you show in some cases is a gear. The DeviceValue of 0 is shown, but the DeviceValue for other values is not shown in your screenshots. The icon for RSSI is range -1 to -126 db are a garage door. This can be confirmed from Status Graphics tab of HS Devices. If A gear icon is showing I think it means DeviceValue is not in the range setup in the Status Graphics tab. This seems to indicate that something else is writing to this HS device with values outside this range. The mcsMQTT debug log will show the HSEvent callbacks that HS provides when it changes a DeviceValue. In more recent version of the plugin an optimization was done to blacklist those that were not used by the plugin so they may not be visible in the log. You can do a HS event on every DeviceValue change and write to the HS log. I could also add debug for each beacon reception and its RSSI if that would help.

[wpiman]

[QUOTE=Michael McSharry;n1496192]

I think that explains why the images are wrong-- the device values are going to the RSSI at times.
/quote]

The icon you show in some cases is a gear. The DeviceValue of 0 is shown, but the DeviceValue for other values is not shown in your screenshots. The icon for RSSI is range -1 to -126 db are a garage door. This can be confirmed from Status Graphics tab of HS Devices. If A gear icon is showing I think it means DeviceValue is not in the range setup in the Status Graphics tab. This seems to indicate that something else is writing to this HS device with values outside this range. The mcsMQTT debug log will show the HSEvent callbacks that HS provides when it changes a DeviceValue. In more recent version of the plugin an optimization was done to blacklist those that were not used by the plugin so they may not be visible in the log. You can do a HS event on every DeviceValue change and write to the HS log. I could also add debug for each beacon reception and its RSSI if that would help.

The mcsMQTTDebug log shows the following....

9/16/2021 7:25:13 AM 252418408 | ActOnMessageForTrigger QueueSize=2 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -87
9/16/2021 7:25:13 AM 252418409 | ActOnMessageForTrigger QueueSize=1 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -76
9/16/2021 7:25:20 AM 252425305 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:20 AM 252425368 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:20 AM 252425419 | ActOnMessageForTrigger QueueSize=5 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -76
9/16/2021 7:25:20 AM 252425421 | ActOnMessageForTrigger QueueSize=1 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -86
9/16/2021 7:25:27 AM 252432252 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:27 AM 252432316 | ActOnMessageForTrigger QueueSize=10 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -83
9/16/2021 7:25:27 AM 252432317 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:34 AM 252439285 | ActOnMessageForTrigger QueueSize=0 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -84
9/16/2021 7:25:34 AM 252439287 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:34 AM 252439349 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:34 AM 252439410 | ActOnMessageForTrigger QueueSize=8 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -77
9/16/2021 7:25:41 AM 252446327 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:41 AM 252446390 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:41 AM 252446451 | ActOnMessageForTrigger QueueSize=5 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -87
9/16/2021 7:25:41 AM 252446453 | ActOnMessageForTrigger QueueSize=1 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -87
9/16/2021 7:25:48 AM 252453280 | ActOnMessageForTrigger QueueSize=14 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -76
9/16/2021 7:25:48 AM 252453281 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:48 AM 252453344 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:48 AM 252453406 | ActOnMessageForTrigger QueueSize=1 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -84
9/16/2021 7:25:55 AM 252460274 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:55 AM 252460336 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:25:55 AM 252460397 | ActOnMessageForTrigger QueueSize=6 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -86
9/16/2021 7:25:55 AM 252460398 | ActOnMessageForTrigger QueueSize=4 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -76
9/16/2021 7:26:02 AM 252467308 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:26:02 AM 252467371 | ActOnMessageForTrigger QueueSize=9 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -80
9/16/2021 7:26:02 AM 252467372 | ActOnMessageForTrigger QueueSize=7 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -87
9/16/2021 7:26:02 AM 252467373 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:26:09 AM 252474276 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:26:09 AM 252474339 | ActOnMessageForTrigger QueueSize=6 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -78
9/16/2021 7:26:16 AM 252481356 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:26:16 AM 252481418 | MQTTReceiveQueue throttling for 50 ms
9/16/2021 7:26:16 AM 252481480 | ActOnMessageForTrigger QueueSize=6 ,Topic Beacon/DC.0D.25.0D.FB.A1,Payload -85
9/16/2021 7:26:16 AM 252481482 | ActOnMessageForTrigger QueueSize=4 ,Topic Beacon/DD.33.0A.11.17.EB,Payload -77
9/16/2021 7:26:16 AM 252481483 | ActOnMessageForTrigger QueueSize=1 ,Topic Beacon/DC.0D.F1.C3.2D.96,Payload -86

I will see about logging the device value from an event, but I suspect it will show what the "Device History" plugin was showing....

I'll also download the latest-- I am at 5.19.1.0

[wpiman]

So I tried the latest plugin and say the same behavior.

I ended up uninstalling the plugin, deleting all of the mcsMQTT files in my Homeseer directory. I reinstalled the latest in the updater. I was able to re-add the beacons and now they appear to be staying stable. They toggle between 0 and -1 which is what we would expect.

It is working, but as a plug in developer I am sure you would like to know what happened, and I am not sure I'll be able to hone in on that now.

[Michael McSharry]

I am glad the issue is resolved for you. If going forward things are looking good then the past is not something that is important. If others in the future have similar problems then your experience and data will be helpful.