Fingerbot receives two messages or reacts twice?

Configuration
,
1

Hi everyone,

I’m having this very strange problem when a Fingerbot switch is toggled in an automation.

I can reproduce the issue: When I trigger automation a UI button, the fingerbot reacts immediately. So far, so good.

But I’ve noticed lately that it’ll sometimes trigger once more, bringing itself out of sync with the state it represents. I have looked through the automation that is governing all triggers related to the Fingerbot and the issue is not there.

After that I had Logbook open and refreshed during the process and interestingly the state change happens is only written once - after the second toggle!

What could be going on here? Is there some retry mechanism going on messaging level messages (z2m) I should look into? Retries wouldn’t be optimal, as the action is not idempotent.

Currently I debug by looking Logbook and also seeing automations getting triggered - how can I peep into what’s going on under the hood?

2

More tests: I tried disabling my fingerbot automation and simply toggle the it from an entity card.

Same result: I click once, one state change is registered in Logbook but the Fingerbot reacts twice.

3

This indeed feels to my like z2m is sending the command, not getting feedbqck, the. trying again and logging the action. Are there enough routing devices between it and the controller, or are some ever taken off power? I think it’s zigbee troubleshooting time.

4

You’ll definitely need to dig into the messages being sent/received by Z2M.
However, note that toggles are, by their nature, not idempotent.

If you want to ensure that only a single action is performed, no matter how many times it’s sent, you will need to use On / Off commands instead of toggles.

5

We’re fairly early in our journey with HA and zigbee (more bulbs incoming!), but in this case yes, I actually think there’s a good chain of bulbs that could act as potential routers. They’re controlled by a zigbee button, so never taken of power.

We’re in an apartment, between coordinator, the potential bulbs and Fingerbot there’s no more than 2 meters of physical space. Based on the map, the current route is:

Fingerbot <=> (LQI: 154) Bulb 3 (closest to Fingerbot) <=> (LQI: 47/255) Coordinator

As I write this, it dawns on me that I’ve actually had previous flaky experiences with most devices in that room at some point. We have a battery based motion sensor that drives a night light for our little one. Even with an open door. I’m wondering it could wifi interference from other apartments or some such?

6

Yep yep, that’s understandable.
But I sadly don’t seem to get any cleverness regarding this from the zigbee device, such as ignoring the action if it’s already on: I just tested a “Turn on” action in a new script and the action will trigger the Fingerbot’s movement, if I run it more than once.

So if I don’t find the source of this repeating issue, there’s always going to be a potential for the state known in HA and the actual state of the hardware the fingerbot mages will drift. FYI, this is the Fingerbot, configured to run in Click mode.

How does one dig into the messages being sent? Is some trace route possible or maybe debug mode where all network messages get logged centrally (in a somewhat readable format :wink:)?

Thanks!

7

Go in the Z2M UI > logs page. Set the level to debug & filter by your fingerbot

8

Ok… got it. I’m seeing this behavior:

Two on entries.

info 2025-04-30 15:35:00</small>`z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Bedroom AC', payload '{"battery":100,"delay":0,"linkquality":47,"lower":85,"mode":"click","program":{"0":255,"1":255,"2":255,"3":0},"reverse":"ON","state":"ON","touch":"ON","upper":0}'`

info 2025-04-30 15:35:00</small>`z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Bedroom AC', payload '{"battery":100,"delay":0,"linkquality":43,"lower":85,"mode":"click","program":{"0":255,"1":255,"2":255,"3":0},"reverse":"ON","state":"ON","touch":"ON","upper":0}'`

I get ONE entry when i use the same button to turn it off:

Info 2025-04-30 15:36:00</small>`z2m:mqtt: MQTT publish: topic 'zigbee2mqtt/Bedroom AC', payload '{"battery":100,"delay":0,"linkquality":47,"lower":85,"mode":"click","program":{"0":255,"1":255,"2":255,"3":0},"reverse":"ON","state":"OFF","touch":"ON","upper":0}'`

I tested a little more, and turns out it also happens the other way around.

I turned off automations during these tests, so it’s only the button that is working with the Fingerbot.

Very strange… without knowing much about the internals, I wonder if there’s some duplicate subscription on the topic set up or some such.

9

Because of the latter, I tried restarting z2m… double entries show up after a few on/off presses…

10

Ok, it seems it happens with other devices as well.

This thread seems like relevant reading while looking into if debounce can help…

11

I do not know your device, but my fingerbot clone can be set to return to start point.
This might actually be the click mode you have set it to use.
Switch mode might be the one you want.

12

FYI, my Fingerbot is taped to the front of an AC panel, clicking the on / off button. In click mode it moves back and forth between position 0 (rest) and100% (click).

You may know this already, I believe switch mode is there to support switches that are physically moved from Up/Down. The arm will move between ends, maybe rest there. I therefore don’t think switch mode would solve my problem, unfortunately (correct me if I’m wrong!).

13

Okay, it was a bit unclear what react twice meant, but it sounds like it moves down, then up and then down and then up. Right?

14

Correct, it does the click action twice instead of just once.

I wasn’t where the issue could be, if it was truly two messages being sent or the Fingerbot reacting twice based on one message, when I started this thread.

However, the z2m log indicates to me that it’s the former situation, sometimes two messages are being sent. It’s very weird.

15

You might want to look into the topicszigbee2mqtt/Bedroom AC/set and zigbee2mqtt/Bedroom AC/get, since those are the ones that are sent as commands to the device.

16

How do I look into a topic like you describe? New platform for me, sorry. Ii didn’t find I could see this information in the Log page.

17

Use MQTT Explorer to see what is going on in the MQTT broker.

1 Like
18

Was gonna suggest this next. Debounce should solve your issues, but you’re cutting it close with the 1s difference between on & off.

Start with the minimum value of 1 for debounce EDIT: 0.5 is an accepted value, so start with that - if you find that the off messages are being ignored, then you might additionally need to set debounce_ignore for state.

Docs are here in case you need them

19

I was actually looking for similar features in the z2m interface, not giving it any thought that I’d need to look elsewhere for this kind of tooling. Much appreciated, thank you!

20

This is great, thank you so much. I set it to 1 yesterday and it’s been running great. We don’t turn it on and off very close in time, so that value should work from here on. Could probably even set it a little higher, but it doesn’t seem like it’s necessary.

While it’s stable now, I’m still very curious why there are double messages sometimes - at least just to learn what the root cause could be.
I’m going to use the MQTT explorer to figure if it’s a higher level problem in HA or at z2m level the problem starts.

Speculation: could it be so that I inadvertently have set some value very low for how long z2m will wait for confirmation from the device - if that’s even a thing? It smells a bit like something that, because it only happens once in a while (meaning that sometimes the potential response makes it back before the deadline).

1 Like