Although the devices support security and “secure if possible” was enabled for all devices, none was added secure…
I added a 1,5m usb extension today, unfortunately i noticed the next couple of jammed notices. But i think these are false positives, because it is all running and always onoy for a couple of seconds.
Unfortunately im at the same stage as last week… have to replace the next 3 batteries.
Are by chance the battery-hungry nodes exposed to cold temperatures?
No, they are still in my house and there is heating. The smoke detectors ran for at least 3 years without any problems on a Devolo Home Control center and had a normal battery consumption of 1 every 2 years. Now I can change them weekly! This is clearly a mistake in the implementation of Home Assistant. I’ll look at it for a maximum of 2 weeks, then I’ll dismantle the whole thing. I’ve already used 40 euros worth of batteries in the last 3 weeks. That’s the disadvantage of such a community solution, that for some problems there is simply no solution because either the developers don’t care or because no one is interested.
If someone asked me, I would provide all the logs, everything I can provide.
shareing zwave communication logs would indeed help i guess , 4 eyes see more than 2.
there the tab logs will show all on debug level, i’ll try to spot stuff and possibly someone else too …
Provide logs, without them we’re in the dark l, guessing.
1 Like
This is a premature assumption. As has been pointed out multiple times in this thread, the problem is just as likely (if not more likely) to be caused by an unhealthy mesh.
And how should i check this? It was running for years with Home Control without taking care at all… I did not find any usefull information, how to analyze this.
Interrestingly, all door/windows sensors and thermostats have no problem. Only the smoke detectors, which are in the same rooms
You have been asked repeatedly to post logs. Please do so. Also you could go into the Z-Wave JS UI and click on the “Network Graph” tab.
As i just wrote, i only found 2 of my smoke detectors in the logs. All others are not there… but even if they are not in the logs, if i raise a smoke alert, it is received from Home Assistant.
Z-Wave ui is not working in my home assistant. It is not showing any data and it raises: “Z-Wave client not connected” error
Purely guessing here, since we have yet to see your logs - but I think you likely have not yet finished your z-wave mesh setup. Meaning, either your z-wave devices were not (all) properly included into z-wave js ui just yet, or you have not even get your Z-stick 7 to talk to Z-wave JS (UI).
- Zwave JS UI or Zwave JS? Which version? Did you install both on the same HA machine? Did you disable/delete one, reboot, before install the other one?
- I assume you are using HAOS. Could you help post your
Setup→Add-onspage? - And then, could you help provide your
Configurationtab under the Z-wave JS (UI) Add-on? - Have you excluded all of your z-wave devices from Home Control?
- After exclusion, have you factory reset / added / included all of your z-wave devices into HA? How exactly did you do that? Are they secured inclusion or otherwise? S0 or S2?
- Have you included your z-wave devices one at a time, verify, before adding the next one?
- What are the z-wave devices you have? I see smoke detectors, what else? How many of each?
- (Again) logs?
People here are trying to help. I’d encourage you work with them, so that we can get to the bottom.
Now as i got z-wave js ui running i have a log available. The batteries are still draining, but it feels like its less fast. On one of my smoke detectors, i noticed the battery beep today, but it was still showed as 100% battery level. Then i requested an battery level update which fixed the shown value to 0. But there is no automatic update. All other devices have no issue, except the smoke detectors.
The node which showed 100% until i actively requested an update is Node 005 from the log. Node 006, 007,010,016,017 are also smoke detectors. Looks like they never actively send their battery status.
For other nodes i can see:
2024-03-05T16:09:11.520Z CNTRLR [Node 025] compat query "Battery"::get()
I never see thet for the smoke detectors, except i request it.
The log is extremely shortend, because i did not find a way to attach the full log here
2024-03-05T06:33:18.383Z SERIAL » [ACK] (0x06)
2024-03-05T06:33:18.387Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -70 dBm
└─[WakeUpCCWakeUpNotification]
2024-03-05T06:33:18.387Z CNTRLR « [Node 005] received wakeup notification
2024-03-05T06:33:18.393Z CNTRLR [Node 005] The node is now awake.
2024-03-05T06:33:18.399Z DRIVER all queues busy
2024-03-05T06:33:18.401Z SERIAL » 0x011000a90001000502840525000000008b6f (18 bytes)
2024-03-05T06:33:18.401Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 139
└─[WakeUpCCIntervalGet]
2024-03-05T06:33:18.425Z SERIAL « [ACK] (0x06)
2024-03-05T06:33:18.426Z SERIAL « 0x010401a90152 (6 bytes)
2024-03-05T06:33:18.427Z SERIAL » [ACK] (0x06)
2024-03-05T06:33:18.429Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-03-05T06:33:18.631Z SERIAL « 0x011d00a98b00001501ba7f7f7f7f02010309000000010100007f7f7f7f7f18 (31 bytes)
2024-03-05T06:33:18.632Z SERIAL » [ACK] (0x06)
2024-03-05T06:33:18.637Z DRIVER « [REQ] [SendDataBridge]
callback id: 139
transmit status: OK, took 210 ms
repeater node IDs: 9
routing attempts: 1
protocol & route speed: Z-Wave, 9.6 kbit/s
routing scheme: LWR
ACK RSSI: -70 dBm
ACK RSSI on repeaters: N/A
ACK channel no.: 2
TX channel no.: 1
2024-03-05T06:33:18.761Z SERIAL « 0x011400a800000100050684060054f60100ba007f7fda (22 bytes)
2024-03-05T06:33:18.762Z SERIAL » [ACK] (0x06)
2024-03-05T06:33:18.765Z CNTRLR [Node 005] [~] [Wake Up] wakeUpInterval: 21750 => 21750 [Endpoint 0]
2024-03-05T06:33:18.771Z CNTRLR [Node 005] [~] [Wake Up] controllerNodeId: 1 => 1 [Endpoint 0]
2024-03-05T06:33:18.774Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -70 dBm
└─[WakeUpCCIntervalReport]
wake-up interval: 21750 seconds
controller node id: 1
2024-03-05T06:33:18.778Z DRIVER all queues idle
2024-03-05T06:33:19.029Z CNTRLR » [Node 005] Sending node back to sleep...
2024-03-05T06:33:19.035Z DRIVER all queues busy
2024-03-05T06:33:19.041Z SERIAL » 0x011000a900010005028408240000000000e8 (18 bytes)
2024-03-05T06:33:19.042Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[WakeUpCCNoMoreInformation]
2024-03-05T06:33:19.048Z SERIAL « [ACK] (0x06)
2024-03-05T06:33:19.049Z SERIAL « 0x010401a90152 (6 bytes)
2024-03-05T06:33:19.050Z SERIAL » [ACK] (0x06)
2024-03-05T06:33:19.052Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-03-05T06:33:19.058Z CNTRLR [Node 005] The node is now asleep.
2024-03-05T06:33:19.062Z DRIVER all queues idle
2024-03-05T06:33:21.164Z SERIAL « 0x011100a8000001000b0320010000ba007f7fd4 (19 bytes)
2024-03-05T14:39:32.041Z DRIVER all queues idle
2024-03-05T14:39:33.149Z SERIAL « 0x011000a8000001000b02840700bd007f7f71 (18 bytes)
2024-03-05T14:39:33.151Z SERIAL » [ACK] (0x06)
2024-03-05T14:39:33.154Z DRIVER « [Node 011] [REQ] [BridgeApplicationCommand]
│ RSSI: -67 dBm
└─[WakeUpCCWakeUpNotification]
2024-03-05T14:39:33.154Z CNTRLR « [Node 011] received wakeup notification
2024-03-05T14:39:33.159Z CNTRLR [Node 011] The node is now awake.
2024-03-05T14:39:33.412Z CNTRLR » [Node 011] Sending node back to sleep...
2024-03-05T14:39:33.416Z DRIVER all queues busy
2024-03-05T14:39:33.418Z SERIAL » 0x011000a90001000b028408240000000000e6 (18 bytes)
2024-03-05T14:39:33.419Z DRIVER » [Node 011] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x24
│ callback id: 0
└─[WakeUpCCNoMoreInformation]
2024-03-05T14:39:33.425Z SERIAL « [ACK] (0x06)
2024-03-05T14:39:33.426Z SERIAL « 0x010401a90152 (6 bytes)
2024-03-05T14:39:33.427Z SERIAL » [ACK] (0x06)
2024-03-05T14:39:33.428Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-03-05T14:39:33.433Z CNTRLR [Node 011] The node is now asleep.
2024-03-05T14:39:33.435Z DRIVER all queues idle
2024-03-05T14:40:02.026Z DRIVER all queues busy
2024-03-05T14:40:02.030Z SERIAL » 0x0103003bc7 (5 bytes)
2024-03-05T14:40:02.030Z DRIVER » [REQ] [GetBackgroundRSSI]
2024-03-05T14:40:02.035Z SERIAL « [ACK] (0x06)
2024-03-05T14:40:02.037Z SERIAL « 0x0107013b9a96967f27 (9 bytes)
2024-03-05T14:40:02.038Z SERIAL » [ACK] (0x06)
2024-03-05T14:40:02.040Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -102 dBm
channel 1: -106 dBm
channel 2: -106 dBm
...
2024-03-05T16:08:26.335Z DRIVER all queues idle
2024-03-05T16:08:44.712Z SERIAL « 0x011100a8000001000b032001ff00bc007f7f2d (19 bytes)
2024-03-05T16:08:44.716Z SERIAL » [ACK] (0x06)
2024-03-05T16:08:44.718Z DRIVER « [Node 011] [REQ] [BridgeApplicationCommand]
│ RSSI: -68 dBm
└─[BasicCCSet]
target value: 255
2024-03-05T16:08:44.719Z CNTRLR [Node 011] treating BasicCC::Set as a report
2024-03-05T16:08:44.720Z CNTRLR [Node 011] [~] [Basic] currentValue: 0 => 255 [Endpoint 0]
2024-03-05T16:08:44.886Z SERIAL « 0x011800a8000001000b0a710506ff00ff0616000000bd007f7f90 (26 bytes)
2024-03-05T16:08:44.887Z SERIAL » [ACK] (0x06)
2024-03-05T16:08:44.889Z CNTRLR [Node 011] [~] [Notification] alarmType: 6 => 6 [Endpoint 0]
2024-03-05T16:08:44.892Z CNTRLR [Node 011] [~] [Notification] alarmLevel: 0 => 255 [Endpoint 0]
2024-03-05T16:08:44.896Z DRIVER « [Node 011] [REQ] [BridgeApplicationCommand]
│ RSSI: -67 dBm
└─[NotificationCCReport]
V1 alarm type: 6
V1 alarm level: 255
notification type: Access Control
notification status: 255
notification state: Window/door is open
2024-03-05T16:08:44.897Z CNTRLR [Node 011] [~] [Notification] Access Control[Door state (simple)] [Endpoint 0]
: 23 => 22
2024-03-05T16:08:44.902Z CNTRLR [Node 011] [~] [Notification] Access Control[Door state]: 23 => 2 [Endpoint 0]
2
2024-03-05T16:08:51.579Z SERIAL « 0x011100a8000001000b0320010000bc007f7fd2 (19 bytes)
2024-03-05T16:08:51.582Z SERIAL » [ACK] (0x06)
2024-03-05T16:08:51.584Z DRIVER « [Node 011] [REQ] [BridgeApplicationCommand]
│ RSSI: -68 dBm
└─[BasicCCSet]
target value: 0
2024-03-05T16:08:51.585Z CNTRLR [Node 011] treating BasicCC::Set as a report
2024-03-05T16:08:51.586Z CNTRLR [Node 011] [~] [Basic] currentValue: 255 => 0 [Endpoint 0]
2024-03-05T16:08:51.753Z SERIAL « 0x011800a8000001000b0a7105060000ff0617000000bd007f7f6e (26 bytes)
2024-03-05T16:08:51.755Z SERIAL » [ACK] (0x06)
2024-03-05T16:08:51.757Z CNTRLR [Node 011] [~] [Notification] alarmType: 6 => 6 [Endpoint 0]
2024-03-05T16:08:51.761Z CNTRLR [Node 011] [~] [Notification] alarmLevel: 255 => 0 [Endpoint 0]
2024-03-05T16:08:51.765Z DRIVER « [Node 011] [REQ] [BridgeApplicationCommand]
│ RSSI: -67 dBm
└─[NotificationCCReport]
V1 alarm type: 6
V1 alarm level: 0
notification type: Access Control
notification status: 255
notification state: Window/door is closed
2024-03-05T16:08:51.766Z CNTRLR [Node 011] [~] [Notification] Access Control[Door state (simple)] [Endpoint 0]
: 22 => 23
2024-03-05T16:08:51.768Z CNTRLR [Node 011] [~] [Notification] Access Control[Door state]: 22 => 2 [Endpoint 0]
3
..
2024-03-05T15:28:21.080Z SERIAL » [ACK] (0x06)
2024-03-05T15:28:21.081Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -103 dBm
channel 1: -106 dBm
channel 2: -106 dBm
2024-03-05T15:28:21.083Z DRIVER all queues idle
2024-03-05T15:28:30.582Z SERIAL « 0x011500498400050e0407015e8559805a7a72717386847e (23 bytes)
2024-03-05T15:28:30.585Z SERIAL » [ACK] (0x06)
2024-03-05T15:28:30.588Z DRIVER « [Node 005] [REQ] [ApplicationUpdateRequest]
payload: 0x00050e0407015e8559805a7a7271738684
2024-03-05T15:28:30.589Z CNTRLR « [Node 005] Received updated node info
2024-03-05T15:28:30.593Z CNTRLR [Node 005] The node is now awake.
2024-03-05T15:28:30.600Z DRIVER all queues busy
2024-03-05T15:28:30.603Z SERIAL » 0x011000a900010005028002250000000007e0 (18 bytes)
2024-03-05T15:28:30.604Z DRIVER » [Node 005] [REQ] [SendDataBridge]
│ source node id: 1
│ transmit options: 0x25
│ callback id: 7
└─[BatteryCCGet]
2024-03-05T15:28:30.609Z SERIAL « [ACK] (0x06)
2024-03-05T15:28:30.611Z SERIAL « 0x010401a90152 (6 bytes)
2024-03-05T15:28:30.611Z SERIAL » [ACK] (0x06)
2024-03-05T15:28:30.612Z DRIVER « [RES] [SendDataBridge]
was sent: true
2024-03-05T15:28:30.739Z SERIAL « 0x011d00a90700000c01bb7f7f7f7f02010309000000010100007f7f7f7f7f8c (31 bytes)
2024-03-05T15:28:30.740Z SERIAL » [ACK] (0x06)
2024-03-05T15:28:30.741Z DRIVER « [REQ] [SendDataBridge]
callback id: 7
transmit status: OK, took 120 ms
repeater node IDs: 9
routing attempts: 1
protocol & route speed: Z-Wave, 9.6 kbit/s
routing scheme: LWR
ACK RSSI: -69 dBm
ACK RSSI on repeaters: N/A
ACK channel no.: 2
TX channel no.: 1
2024-03-05T15:28:30.864Z SERIAL « 0x011100a80000010005038003ff00bb007f7f86 (19 bytes)
2024-03-05T15:28:30.866Z SERIAL » [ACK] (0x06)
2024-03-05T15:28:30.867Z CNTRLR [Node 005] [~] [Battery] level: 100 => 0 [Endpoint 0]
2024-03-05T15:28:30.871Z CNTRLR [Node 005] [~] [Battery] isLow: false => true [Endpoint 0]
2024-03-05T15:28:30.874Z DRIVER « [Node 005] [REQ] [BridgeApplicationCommand]
│ RSSI: -69 dBm
└─[BatteryCCReport]
level: 0
is low: true
I see your route speed is listed at 9.6kbit/s. According to this post reply from one of the devs, the 9.6kbit/s route speed is only used as a failback. If your devices are using this speed you have interference, a repeater issue, or something is wrong with your device. I’m using old 300 series devices and they have route speeds of 40kbit so yours should be higher.
No idea, why it takes that route, which is using the most far away devices as relay:
The smoke detector (Rauchmelder) is at the base level, the “Stecker Marie” is in the 1st floor and “Stecker Weihnachtsbaum” is also at the base level.
The plug is about 4m from the smoke detector, which is perfectly working. It makes no sense to use this strange route from the 1st image.
I also rebuilded the routes multiple times, but it doesnt change this non sense routing through multiple levels of the building althoung it has a routing capable device nearby which i btw. part of that strange route.
The route also looked different a couple of days ago. This may be connected to the current battery status…
But does a bad signal route explain, that the devices do not submit thier battery status + drain their batteries in a short time?
I can rule out that the devices are defective, everything went perfectly for a long time and since the change from Devolo Home Control to Home Assistant, this has happened to all smoke detectors and they certainly do not break all at once.
The routing decisions are made by the zwave stick firmware not by zwavejsui. So changes you see in routing are due to the firmware version and the RF environment.
RF communications are subject to a lot of reflection and interference. Hence the device very nearby may not have the clearest signal. I find that WIFI (base stations, laptops), microwaves can cause distrubances. Many zwave plugs seem to be poorly isolated from the load going through them - as an example I have a smart plug in line with a gas water heater - whenever the water heater is on - the RSSI and RTT to the switch deteriorate.
2 Likes
Is your device going back to sleep or is it stuck in a permanent wake-up mode?
1 Like
Due to the logs its sleeping and normally only seen once a day and when i request updates and press the button. My current logs are a bit full, because of some requests for status updates (battery etc.) … The only affected devices are these smoke detectors. All other z-wave devices, also some near by door sensors, have normal power consumption. The issue is isolated to these smoke detectors
I’d enable the diagnostics sensors on that device that show the TX and RX counts, add them to the recorder, then look at a history chart and see how often they are TX or RXing.
i changes the battery today, now it also shows a better route. But it did NOT update battery by itself, i neded to refresh values
@ PeteRage: Where do i find/enable the diagnostics sensors?
I also did a health check:
