Old Aeon Outlet turns on but no log entry and status show off (New developments)

I've had this outlet connected for years without a single issue. Lately it seems to turn on every evening, but the status still shows off under devices. There is no indication in the logs that anything turned it on. I deleted all apps that reference this outlet except one that turns it off. That app is triggered when the outlet turns on and it is not getting called because the status never gets updated. I can tell you that if I hit POLL or REFRESH under the device page, the status updates to show on, then that app I have runs as expected. I have removed Alexa as well for this device. I am baffled as to why it suddenly turns on every night. Any suggestions on other things i can try. I think my next move is to remove it, and reinstall it, but if that fixes the issue, I will never know what broke so I will learn nothing form the experience.

Which apps use this device, as indicated on the device page in the "in use by" section. For example:

1 Like

The new device event logs should show the source of the event.


I looked at that new log and there was some info, but oddly it was incorrect about being on at 10:52PM. I know it was wrong because I had to turn it off at 10pm and I checked it again at 11:30pm when I went to bed. It was definitely off. Even more odd stuff, notice how it suddenly stated reporting power usage this morning at 7:03am. There were no ON commands logged between 11:30pm when I checked it and 7:03am, but is suddenly started using power. When I went out this morning you can see where I used my button to turn it off. For what it's worth, I have disconnected all automations and the button already, but it keeps turning on. I put the button back on because it makes it easier to turn off

At the moment, I have these connected. I have removed these and it was coming back on so I don't think they were the cause. The smoke alarm has a turn OFF command in it. There are no turn on commands. This outlet runs a fan so I want it off if a fire is detected. This routing also turns all the house lights on and that has not been happening, so I really don't think that app has been firing. The button is just a button I added so I can turn it off easier. It was not there before so it should not be causing any issues. I am baffled. See also the post below for the log info. Odd stuff.

What driver is used with this Aeon outlet?

The built in "Aeon Outlet? Driver. It's worked flawlessly for years though.

I asked because the events log that you published contains some non-standard events like "command-off", haven't seen something similar until now in other inbuilt drivers. There was a bug found recently for another device after the latest platform update, just thought the two different issues may be related.


No ideas, I guess I am not the only one stumped. I changed the driver to Generic Zwave Outlet tonight. It does turn on and off normally with that driver. I will watch it tomorrow and see if it behaves differently and report back.

Test results from changing the driver showed no changes. I decided to remove the device completely from my hub via exclusion, then I reset the device and reinstalled it via inclusion. After 24 hours, it seems to be working normally. I will report back if anything changes, but at the moment it appears that removing it and reinstalling it may have fixed things. Time will tell.

Don't know if anyone is following, but the Aeon outlet seems to be working normally after a complete removal and reinstall. But that is not the end. Now I have an Innovelli outlet and a hallway light that is turn on without any trigger. I was sitting here when the hallway light came on, nobody around and it just turned on. I checked the logs and it said physical switch. Both devices have turned on without warning and log as a physical switch but nobody touched them or any dashboard commands. It seems like there is a command running wild on the Z-wave network and it just moves to the next device(s) after you remove an effected device. This is crazy weird. Does anyone have any ideas before I just factory reset the entire network and start over? I really do not want to go to this extreme.

That's a platform log entry. It is created whenever a command is called on the device, usually by some app or device's parent. No drivers explicitly produce these. This is a new thing for 2.3.3.

1 Like

Here is the log from last night when my Innovelli outlet turned on at 3:17am. There are no automations configured for it except one that turns everything off at 11pm daily. Any other ideas?

The two incidents may not be a coincidence that they happened back to back. The initial incident may be caused by the outlet being too far away from the hub, or that the repeater it relies on to communicate with the hub may have had a problem, whereas the physical event of Inovelli outlet is solely a malfunction of the device itself. Hubitat hub just received the event that the Fence Outlet was turned on, the command wasn't initiated from the hub.

I had considered the distance issue. I have a gate sensor and one more Innovelli outlet that are even farther down the fence line that work flawlessly. Not sure the distance is the issue. I have run a Z-Wave repair and it made no difference so far. The second point I would add is that my hallway light also started to turn on unexpectedly in the same manner. That light is 12 feet away through 1 sheetrock wall. Any other thoughts or suggestions? Should I be using Zigbee devices for my long distance items? I only have a couple things out there ad could easily change those out.

Unfortunately, the distance is not always the best measure to determine if a device can communicate reliably with the hub. "The Z-Wave radio signals may bounce off metal objects like mirrors or appliances and cause two nodes that are only a few feet apart be completely unable to talk to each other due to reflections of the radio signals. " Dr. Wave - Seven Habits of Highly Effective Z-Wave Networks for Consumers

Agreed, but nothing has changed in the network. My car is always parked in the same spot. I am baffled. I code industrial machinery, so I understand a great deal about noise interference, reflective waves, mesh networks etc. I run into it all the time. I have tried a lot of different testing to eliminate as much as possible but so far, no luck. The first device I had problems with was the Aeon outlet. Once I removed it, reset it and reconnected it to the network, it is working fine in the same location it was in before. Seems like it would go back to it's old behavior if it was reflected waves etc. Z-wave is new to me, I admit, but radio waves are not.

The device upon inclusion could have picked a less noisier route. As for the Inovelli, that is a device issue. Determining why it reported physical actuation is the key, there. Perhaps an issue with the firmware that the device is running or a hardware malfunction on the device.

Thanks, I will probably replace the Innovelli with another one that I am not using in another location. What are your thoughts on me possibly adding another hub dedicated to the devices outdoors. If my issues are reflected waves and routing, would segmenting the network in this way prevent indoor and outdoor devices from trying to route through each or would bridging the hubs allow them mesh back into each other in any way? I read the article you posted and it all seemed to align with my understanding of things so far. What I am not familiar with is the inner workings of the Z-wave protocol so I do not know the life cycle of a message on the network. If I am reading between the lines correctly, it sounds like a message could float around for a while if the intended target does not pick it up. Is it possible it could receive an "on" command twice via 2 routes? Maybe it was turned on via a route through device "A" but the same command go stuck in a route via device "B" for a few hours, then suddenly gets delivered? This is why I am asking about segmenting via 2 hubs.

Running separate hubs would have separate meshes..

It is possible if received through 1 route but ack could not be returned, causing a re-transmit.

This should work well.