Node Red not triggering automations on specific device

A friend gave me a bunch of Gosund wifi switches. I took it as an opportunity to learn how to flash firmware and dive into the world of Tasmota. I successfully flashed 9.2.0(lite) on all of them. Using Node Red, I set up some basic on/off using the Big Timer node to have them come on/turn off at sunset/sunrise, respectively.

Everything seemed to be working well for months, but I came back from a vacation recently and noticed they were no longer responding to the rules. I’ve checked their wifi connections and debugged directly in NR and I can manually turn them off through each node. Even weirder is that according to NR the on/off signals are being sent properly. The device just doesn’t appear to respond?

Errors in the homeassistant log? Node red log?

Ah good call. Unfortunately, I’m not sure how/if I can access the log events pictured above. I see a lot of this in the NR logs:
13 Jul 21:31:29 - [error] [api-call-service:Bug Zapper Stables] Call-Service attempted without connection to server.
13 Jul 21:31:29 - [error] [api-call-service:Bug Zapper Kitchen] Call-Service attempted without connection to server.

But I see that warning for a ton of devices that seem to be operating just fine. Is there a good way for me to specifically capture the logs around the time the event is supposed to fire?

Hm… that can be due to restarting homeassistant and node red not having connection to it?

What is also possible … do you have mqtt running to send the command to the gosunds?
What if the wifi is not good at that time? Homeassistant doesn’t know that (yet) and so does NR… hence it “firing” the command?

I haven’t set up mqtt in any way (not explicitly anyhow, unless it’s happening under the hood somewhere?).

In a nutshell, all of my hardware is paired to a Hubitat hub which I pipe into HA using the HACS integration (I prefer HA as a rule machine/front-end UI). I did install the TasmoAdmin panel specifically for these switches (which might be redundant?) but I like the extra info it provides. Specifically, the wifi strength percentage (the plug in question is consistently 70% or above). But really, the most important part is that everything was for sure working at a certain point. There have been a handful of HA updates which could be part or all of the issue?

NR has generally been stable for me so It’s unclear why some of the switches would or wouldn’t be working…

That’s high, you could set a simple ping sensor to see how accessible it is.

1 Like

Sorry, that’s too many links in the chain for me to help troubleshooting.

Oh cool! Never used the ping node before…

So I hooked it directly to the turn_on call service node and the device turns on as expected. More proof that the plug is functioning correctly? Still unclear why the NR automation doesn’t get it to fire at the desired time…

A ping sensor in HA. It will test the connection. After a few hours you be able to see if it’s sporadically dropping off line.

  - platform: ping
    host: 192.168.device.ip
    name: "senor name"
    count: 2
    scan_interval: 60