Did you check that everything that came on is definately exposed in Alexa - Manage Entities?
Good question because, despite my detective work, I’m not completely convinced the Amazon Echo Hub node was at fault. The available evidence leads to its doorstep but it may not be the end of the trail of clues.
The fact is it is that only about 90% of the devices the node can control were turned on (the remaining 10% were not). If the node was the source of the glitch, it’s curious it turned on some but not all of its controllable devices (for example the Logbook has no record of a few lights the flow can control).
Node-Red can show debugging information but I have nothing available to indicate if any command was received. The only evidence the flow was involved is shown in the posted screenshot. The final service call node had been executed at 21:47.
Back in the X-10 days this happened pretty frequently due to a nearby lightning strike or other power surge….
Must be a YMMV situation because I had many X10 dimmer switches in the past and, over a period of almost 10 years, never experienced an accidental “all lights on” event.
I currently have a mix of UPB and Zigbee lights (Philips Hue) and all of them turned on plus a Tasmotized switch, one X10 outlet, and several other devices (sprinklers controlled by relays in an ELK M1).
What they have in common is they are controllable via a Node-Red flow that makes them all voice-controllable. That’s why the prime suspect is that flow, notably its Amazon Echo Hub node that receives voice-commands for a given device and controls it via the service call node (effectively it operates like the Emulated Hue integration).
I will have to do some research to find the neatest way to log all activities for just that one flow. Should this glitch ever recur in the flow, at least I may have more insight into what caused it.
I have a catch node set for all nodes that feeds into a text file. It won’t log all calls but it will log all errors. And being that i write it to a text file, it holds everything until you choose to delete it.
E.
Taking a quick look there seems to be a way to output the full log, I not home to try it though. About 8-10 posts in
1 Like
Are all the devices that turned on Zigbee controlled? If so, I’ve experienced the same thing during momentary power outages. It never happened before about 4 core upgrades ago. (PI3B+, Conbee II tongle)
Thanks for the tip; I will check out the post.
No; several integrations were involved (see my previous post for the details).
1 Like
Does Alexa have a log of voice commands? I use Google rather then Alexa so I’m not as familiar with it but I know with Google I can get to a log of all recent voice commands. Also I believe with Google there’s some incredibly broad “everything on” commands for some reason, perhaps Alexa has those too and thought it heard that?
EDIT: oh sorry, you checked Alexa’s log. Hrm very strange. Does the app UI log things there? Is it possible someone hit the light widget either accidently or on purpose in the Alexa app UI not realizing everything in the house looks like a light?
It does but, as mentioned in the first post, there’s no record of any command at that time. FWIW, the last command occurred several hours earlier and it was a query about the weather.
It’s entirely possible that the Amazon Echo Hub node behaved like it was responding to a “turn on all lights” command (although there’s no record of it receiving that command). It emulates a Philips Hue Hub so it treats everything it sees like a Philips Hue light. When you say “Turn on the furnace fan” it assumes it’s turning on a light. This flow is used to voice-enable several real Philips Hue lights and many devices that are not (X10 outlet, ELK M1 relays, Tasmotized plug, furnace fan controlled via MQTT, etc). Basically, most everything that it controls got turned on. Unfortunately, why it did it is still unknown.
FWIW, we were watching TV at the moment it happened so all persons able to invoke an “all lights on” command were present and accounted for.
Also poking around I noticed this open issue in the GitHub repo for the node you linked
The author of that issue sounds like they’re hitting it a lot more frequently then you are but does sound like the same behavior you described.
1 Like
Interesting; thanks for the link. Fortunately I am not experiencing the problem as frequently as the Issue’s author. However it sounds like the same problem.
This is the first time all the devices were turned on (and this node’s code hasn’t changed in a long time). I recall one previous strange incident that I now believe might also be due to this node. We arrived home to discover the lawn sprinkler was on. The history showed it was turned on just over 4 hours earlier (when no one was home). I couldn’t explain why it was activated but had a hunch it might have been due to Amazon Alexa (although I didn’t point a finger at the Amazon Echo Hub node at the time). To guard against this undesirable behavior, I added two fail-safe mechanisms:
- Turn off any sprinkler that runs for more than 100 minutes.
- Turn off any sprinkler turned on during the off-season (that’s what kicked in yesterday and turned off the sprinkler relays).
1 Like
Hm yea, definitely concerning. Another thing I might suggest is simply logging every message that comes out of those nodes to some text file. Nothing in node red happens without a message and I assume your function node cannot randomly start sending messages.
Perhaps it unexpectedly sends a message either on connection error or some kind of status change with alexa. If so it can likely can be filtered out by looking at the message data but you’d have to be able to separate it from the good messages when someone actually told Alexa to do something.
Or if it’s unrelated to this node then youd know that too since there would be no message log.
Could I talk you into posting a snippet of that automation to turn stuff off that is out of normal parameters? I’ve been noodling how to do that so when it happens to me I don’t come home after being gone for a few days seeing every light interior AND exterior brightly lighting up the neighborhood for who knows how long.
btw: I am also using the Alexa Smart Home Devices interface but just Zigbee stuff. I noticed an “All Lights On” Alexa command that it generated but I don’t have any group named “All Lights” in my ZHA configuration.
I’d rather not post code for the fail-safes I’ve created because it’s liable to cause a fair bit of thread-drift. However, I don’t want to leave you empty-handed so here’s an outline of what I implemented.
Creating fail-safe mechanisms largely depends on the situation. For the sprinklers, I have three “safety nets” involved:
-
There’s a default value for the sprinkler’s duration (30 minutes). In other words, if you simply turn on a sprinkler (whether by voice-command or the UI), the sprinkler’s timer is always set to 30 minutes.
-
The sprinkler’s duration is hard-limited to 100 minutes. If you attempt to specify anything greater than 100, it uses the default value of 30.
-
If for some inexplicable reason the sprinkler is detected to be on for more than 100 minutes, it’s turned off.
Item 3 is simply a State Trigger with to: on and for: '01:41:00 (1 hour and 41 minutes = 101 minutes). This isn’t ideal because when you execute Reload Automations (or restart Home Assistant) a State Trigger’s for option is reset. However, it’s the simplest way to implement the mechanism. Eventually I will change it to a Time Trigger whose scheduled value is set 100 minutes into the future the moment a sprinkler is turned on (this survives restarts/reloads).
For the pool light, it’s simply an automation with a State Trigger that monitors the light’s state. One option in the action's choose checks if the light was turned on but binary_sensor.pool_season is off. In that situation, it turns off the pool lights (and logs a warning message).
NOTE
In case you’re wondering why the sprinkler duration is 100 minutes it’s because the Hue emulation treats the sprinkler as a light. So if I say “Set lawn sprinkler to 95”, Alexa readily accepts the verbal command because it assumes I am setting a light, called lawn sprinkler, to 95% brightness. However, my Node-Red flow uses the received command to turn on the lawn sprinkler relay and set the sprinkler timer to 95 minutes. Maximum light brightness is 100 so that becomes the sprinkler timer’s maximum duration.
1 Like
After some digging around I was able to find what should be the error log in the nodered container @ /var/log/nginx/error.log except it was blank.
I enabled audit and metrics inside settings.js and was able to see the increased output in the addon log. audit gives you all api calls and metrics gives flow activity and memory use.
Finally I added to the init commands in the addon '> /var/log/error.txt', the above link I posted shows this to output a text file of the log. It creates the file but again is empty.
I assume this is all due to the output being routed to the addon log, any ideas where it may be storing this log file?
Docker containers send their logs to stdout as a best practice rather then a file so that the log strategy can be set for the system as a whole. In HAOS or supervised HA the strategy is journal logging. See this guide for how to get to and browse the system journal:
Your logs for core, supervisor and all addons will be in there. Logs for addons will be tagged with the addon slug.
Additionally there are a couple other ways to get to your logs from the CLI. Easiest way is just this:
ha addons logs a0d7b954_nodered
That only shows you the logs since the last restart of that addon though.
If you have the Terminal & SSH addon installed (the one from the community repo) with protection mode off or have access to the docker CLI via some other means you can also do this:
docker logs addon_a0d7b954_nodered
Which will show you all logs for a container with that name across restarts. Add -f to follow/tail it.
1 Like
The Node-Red Add-on’s log is also displayed in Configuration > Add-ons > Node-Red > Log.
I can confirm it contains the same information as what is displayed by ha addons logs a0d7b954_nodered. I recall looking at this shortly after the glitch occurred and the log was empty.
I imagine I would need to tweak some setting in the Add-on’s configuration to make it more verbose.
Apologies if my last post on the Node red palette veered off base, but did you ever get to the bottom of what happened?
The reason I ask is last week I also had a “ghost” activation of devices, but it was more concerning . Two doors unlocked and my garage opened while home alone. Without going into too much detail I locked down additional security settings and haven’t had an issue since.
Although our install types are different, there are some common points like Node Red being used for Alexa control (I use a different palette though so not “apples to apples”) so just curious what you may have found.
See CentralCommand’s post above containing the linked Issue in the node-red-contrib-amazon-echo repo.
1 Like
