Call Service Node - Message getting lost?

I’m looking for a bit of help with a simple but annoying issue.
All within Node-Red and using Home Assistant nodes
In simple terms I’m just using an Alexa voice trigger to fire a Call Service node to fire the switch
The switch is a 4 gang Zigbee switch (it’s a bare board TuYa TS0004).
It works fine except for randomly, but generally after a long period of inactivity, have to ask Alexa twice before anything happens.
When initially triggered I get all the correct debug messages from Node-Red but nothing happens at the switch. I have monitored the Zigbee2MQTT logs and can confirm no message arrives from the trigger.
If I then re-trigger, everything works perfectly, exactly the same debug output from Node-Red as before but this time the messages are visible in the Zigbe2MQTTlog and the switch toggles.
It’s seems the initial node messages are created and sent but get lost somewhere on the way to Zigbee2MQTT ?
Anyone got a clue what might be going on here ?

I’m debugging a similar issue. It seems that service calls from node red don’t always make it to HA. In the logbook of the entity, I don’t see the activity. This makes me think the call is not getting to HA (vs from HA to the device). The item in question is a zigbee bulb via ZHA.

Did you have any luck resolving?

Unfortunately, no. I’ve still got the issue and would still very much like to get it sorted.
I have a partial work around but it’s far from ideal…
The switch I’m firing moves some electric gates which also have a contact sensor on them.
I’ve altered the Node-Red flow to monitor the contact. If the contact doesn’t show as open after a couple of seconds I re-fire the switch and repeat until the contacts show as open.

The only thing I have uncovered is that it might be the coordinator causing the problem ? I need to find some time (and the courage) to update my coordinator to the latest firmware as mine is over a year old. I’m using a ZZH from Electrolama in case yours is the same ?

I did a little more debugging and actually think it’s no longer a node-red issue, but instead a zigbee issue of sorts. I noticed two things:

  1. On HA boot, I’m starting to see more errors like this. I normally would see these when a device runs out of battery, but the devices I’m seeing now are powered by mains. I’ve never had issues with these devices before (and I have a lot of the same devices (bulbs) on the network without issue). This is making me think it’s a coordinator/network issue.
  2. In HA, I sometimes cannot get these bulbs to function either. Clicking the switch does not add to the logbook until the device reports back that it’s on. So I don’t think NR is the culprit.

I was thinking of doing a workaround as you suggested, but eager to resolve the core issue. I have a hunch it might have to do with one of my repeators and signal loss, but TBD. It’s odd though, this issue seemed to pop up after I made updates to HA/node red, but that could purely be coincidence.

I’m using this coordinator. Have had it since 2018 and never updated firmware… Could give that a shot, but as you mention, need to work up the courage to do it!

I’ll report back with any findings. I did try moving one of my repeators to see if it makes a difference.

Ok thanks for the info. Hopefully two heads are better than one.
So, I don’t get any reported errors like yours. I seem to see all the correct messages but just no action from the switch. It just ignores me !
I do also have similar issues with some BRT-100-TRV’s from Moes. These seem to do the same sort of thing. Occasionally, they just ignore me (again, no errors). Only a battery out and back in will sort them.
That got me to the same point as you - repeaters/signal loss etc. That said I have 62 Zigbee devices of which 38 are repeaters. I have already tried moving some of the repeaters within 1M of a problematic TRV - it doesn’t seem to make a difference. I’ve also moved an Ikea dedicated repeater right next to the gate switch with no improvement.
I’ve also thought it might be something to do with QoS so I tried it set to 2 in Z2M for a good while. No difference. - Although I’m not 100% confident I’m setting it up correctly. I’m unsure if you have to set it in 2 places ? i.e. once in Z2M and once in Mosquitto, resulting in a Qos between Z2m and Moquitto and another Qos between Moquitto and the end device ?
Like you I have a good number of bulbs on the system, 20 or so. I’ve heard that bulbs don’t make good repeaters ? - Now if that’s true and we are both having the same sort of issues could that be an avenue we should explore ?
My property is quite spread out so switching off all the bulbs is going to break the network in any event I think.
Sorry, I’ve rambled on a bit there but wanted to get all my thoughts out there in one !

After moving one of my repeaters and waiting a few days, my zigbee issues are not as prevalent. The repeater I moved (ikea tradfri) was in a corner in the basement - I’m guessing devices thought it was good to connect to, but then there was too much signal loss. I noticed that some devices were connected to this repeater even though it didn’t make much sense. Long story short; I think there was some connectivity issues causing problems; moving the repeater helped. I may pick up another repeater to to help keep things running smooth.

Re: bulbs acting as repeaters - I’ve heard they are not good as well. 1) they are usually surrounded by a bunch of metal and 2) most light sockets are on a switch - if the repeater loses power, it breaks down the network. I’m not sure which bulbs you have, but the ones I use (sengled) purposely do not act as repeaters because of these issues. My only repeaters are 2 tradfris and 2 outlets.

Hope this helps - I’ll report back with any other findings!

Thanks for the update. I have also tried moving repeaters which seems to make things better (not perfect) for a while.
I honestly think it’s time for me to put my big boy pants on and upgrade the coordinator firmware !
I’ll let you know how it works out.

Just FYI the big boy pants have been worn ! I updated the coordinator firmware yesterday and to be honest it didn’t go that badly. The flashing part was easy enough. I did have some trouble getting Z2M back up as it couldn’t find the coordinator. Once I found out where the path setting was (which was Z2M integration, config - not any of the relevant YAML’s) it worked perfectly. No loss of any Zigbee devices or config and no re-pairing at all.
Time to start monitoring and see if it makes a difference !

Good to hear! Have you noticed any improvement yet from the firmware update?

I’ve been having some intermittent issues again. I think I’m going to buy a few more tradfri repeaters to get a little better coverage.