Contribute to Open Source. Search issue labels to find the right project for you!

zwave devices marked as invalid_node

athombv/homey

What is your Homey version (Settings → System)?

1.2.2

What did you try to achieve?

Removed some zwave devices and tryed to repair. Repair worked couple of times, after that no more. Last repaired devices are all marked as invalid_node. Even one older device (fabro roller shutter) is now marked as invalid_node. Removing zwave from settings is working, but the device is still here. Removing with the cross from devices and timeout is working. Removed devices now unpossible to pair.

What was the result?

Dead devices, zwave unusable, pairing not possible, removing old devices problematic.

What did you expect as result?

Working zwave

Any other remarks

Zwave IDs are over 200 atm, maybe i have the max. IDs used? Is Homey not restarting with the zwave ID Nummbers? PTP and Rebooted many times, not better

Please attach a Homey System log (Settings -> System -> Send Log)

557E168C2B is a new one, 3F06DE6438 older (better) one

Updated 24/04/2017 11:34

[Z-Wave] Stuck on removeNode loop

athombv/homey

What is your Homey version (Settings → System)? 1.2.2

What did you try to achieve? Removing a Node

Please include detailed steps how we can reproduce the issue I’m not fully sure what causes it to fail on the removeNode. It just gets stuck, and when trying to restart the removal it will restart, but won’t continue (wait for z-wave) if you then abort you get this in the log: [2017-04-22T13:13:02.906Z] Command[204] start: removeNodeAbort [2017-04-22T13:13:02.912Z] Command[204] end: removeNodeAbort [2017-04-22T13:13:02.920Z] Command[205] start: removeNode Aborting again (the remove node buttons is still active) it will abort but nothing happens: [2017-04-22T13:18:51.466Z] Command[206] start: removeNodeAbort [2017-04-22T13:18:51.471Z] Command[206] end: removeNodeAbort

What was the result? Not able to remove, or add a new device, a reboot is needed to get it working again

Any other remarks Has been there longer, but could (and still can) never reproduce the issue consistently. Usually happens when trying to include -> remove -> include multiple times after each other But always stuck on the Remove Node part currentProcess: ProcessRemoveNode

Please attach a Homey System log (Settings -> System -> Send Log) 0127016A35

Updated 24/04/2017 12:14 1 Comments

[Z-Wave] UNencapsulated Notification CC not being recognized

athombv/homey

What is your Homey version (Settings → System)? 1.1.2

What did you try to achieve? in this particular case, use Power Management Notifications as possible flow triggers. But have seen more Notification CC being addressed as Unknown CC 0x7105000000ff080c0000 <= Notification, Power Management, Battery is charging 0x7105000000ff080d0000 <= Notification, Power Management, Battery is fully charged 0x7105000000ff08000000 <= Notification, Power Management, Event inactive Examples of known notifications ~all have 1 byte less at the end~, and are gotten in the security cc: (added 0x71 for the command class manually) 0x71 05000000ff090100 <= Notification, System, System hardware failure 0x71 05000000ff010300 <= Notification, Smoke Alarm, Smoke Alarm Test 0x71 05000000ff080a00 <= Notification, Power Management, Replace battery soon

Please include detailed steps how we can reproduce the issue device with unknown Notifications => Aeotec Wallmote (ZW130) => Aeotec Multi Sensor 6 (ZW100) (not in the list, have seen Unknown CC) devices with known notifications => Fibaro Smoke Sensor z-wave plus (fgsd-002)

What was the result? The notification is seen as unknown command class and thus not able to be used

Any other remarks almost looks like aeotec related now. but i think it has got more to do with encapsulated (security CC) being parsed differently

EDIT: UPDATE it definitely is the parser, same device but included as secure does get the notification recognized (added 0x71 for the command class manually): 0x71 05000000ff080c0000 <= Notification, Power Management, Battery is charging

Updated 20/04/2017 12:32 2 Comments

[1.2.0-1.2.2] Z-wave devices timeout / not responding to commands

athombv/homey

What is your Homey version (Settings → System)? 1.2.0 (latest non-RC experimental release)

What did you try to achieve? When going to bed, I would like to switch off all lights standby consuming devices, as defined in a flow (triggered by scene command from the dimmer-2). Lights (individual and triggered within a flow) are triggered first, standby killer actions are triggered 2 minutes later (to allow for lights to switch of first

What was the result? Since the introduction of RC12, not all lights are responding to this flow and are showing timeout messages. 170413_flow-night

This was working ok before RC12.

See extract out of 170413_Z-wave log.txt: [2017-04-13T07:13:16.334Z] ProcessSendData[2531]: To node: 26 with data: 0x320100 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:23.063Z] ProcessSendData[2531]: Error: timeout [2017-04-13T07:13:23.068Z] ProcessSendData[2532]: To node: 23 with data: 0x320100 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:28.817Z] ProcessSendData[2532]: Error: timeout [2017-04-13T07:13:28.821Z] ProcessSendData[2533]: To node: 24 with data: 0x320100 and txOptions: ACK,AUTO_ROUTE [2017-04-13T07:13:29.850Z] ProcessSendData[2534]: To node: 25 with data: 0x600d1905320110 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:36.999Z] ProcessSendData[2534]: Error: timeout [2017-04-13T07:13:37.005Z] ProcessSendData[2544]: To node: 8 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:44.127Z] ProcessSendData[2544]: Error: timeout [2017-04-13T07:13:44.134Z] ProcessSendData[2543]: To node: 5 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:51.852Z] ProcessSendData[2543]: Error: timeout [2017-04-13T07:13:51.862Z] ProcessSendData[2542]: To node: 7 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:13:55.240Z] ProcessSendData[2541]: To node: 2 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:14:00.969Z] ProcessSendData[2541]: Error: timeout [2017-04-13T07:14:00.975Z] ProcessSendData[2540]: To node: 3 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:14:04.040Z] ProcessSendData[2539]: To node: 6 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-13T07:14:09.697Z] ProcessSendData[2539]: Error: timeout

Updated 29/04/2017 15:22 9 Comments

[1.2.0] Z-wave battery devices (motion sensors) queried by Homey for security info while asleep, blocking communication

athombv/homey

Follow-up of #1442 (2nd instance mentioned), on request of @jeroenvollenbrock split into separate issue; also since multiple users report the same issue

What is your Homey version (Settings → System)? 1.2.0 (latest non-RC experimental release)

What did you try to achieve? Fibaro motion sensor-plus to report motion instantly

What is the result Delayed response / no response at all from the motion sensors In some cases, manually waking up the motion sensor solves the issue / clears the queue of requests

Observations Out of the Z-wave log, it appears that Homey is querying the motion sensor for it’s security key while the sensor is not awake…

Section out of the 170412_Z-wave log.txt; node 19 and 20 are the Fibaro Motion sensors: [2017-04-12T21:17:10.507Z] Node[20]: Received application command for COMMAND_CLASS_SECURITY, data: 0x40 [2017-04-12T21:17:10.509Z] Node[20]: sendData to COMMAND_CLASS_SECURITY, params 0x80b23f098ea3ab608a [2017-04-12T21:17:10.511Z] Command start: sendData [2017-04-12T21:17:10.547Z] ProcessSendData[512]: To node: 20 with data: 0x9880b23f098ea3ab608a and txOptions: ACK,AUTO_ROUTE [2017-04-12T21:17:10.870Z] Node[20]: Received application command for COMMAND_CLASS_SECURITY, data: 0x40 [2017-04-12T21:17:10.875Z] Node[20]: sendData to COMMAND_CLASS_SECURITY, params 0x80249dd92081f1500f [2017-04-12T21:17:10.875Z] Command start: sendData [2017-04-12T21:17:10.995Z] Node[20]: Received application command for COMMAND_CLASS_SECURITY, data: 0x40 [2017-04-12T21:17:10.996Z] Node[20]: sendData to COMMAND_CLASS_SECURITY, params 0x8018005350d7f57d83 [2017-04-12T21:17:10.996Z] Command start: sendData [2017-04-12T21:17:11.979Z] Node[20]: Received application command for COMMAND_CLASS_SECURITY, data: 0x8117e692ca890e5d2fd85457e6b858661bdc3cb227bfec179dd3344c [2017-04-12T21:17:12.006Z] Node[20]: Decapsulated frame from COMMAND_CLASS_SECURITY to COMMAND_CLASS_NOTIFICATION, data 0x05000000ff070800 [2017-04-12T21:17:12.542Z] Node[8]: sendData to COMMAND_CLASS_SWITCH_MULTILEVEL, params 0x014f05 [2017-04-12T21:17:12.543Z] Node[8]: sendData to COMMAND_CLASS_SECURITY, params 0x40 [2017-04-12T21:17:12.543Z] Command start: sendData [2017-04-12T21:17:14.092Z] ProcessSendData[512]: Error: TRANSMIT_COMPLETE_NO_ACK [2017-04-12T21:17:14.097Z] ProcessSendData[515]: To node: 8 with data: 0x9840 and txOptions: ACK,AUTO_ROUTE,EXPLORE [2017-04-12T21:17:14.103Z] Command end: sendData [2017-04-12T21:17:14.242Z] ProcessSendData[514]: To node: 20 with data: 0x988018005350d7f57d83 and txOptions: ACK,AUTO_ROUTE [2017-04-12T21:17:14.247Z] Command end: sendData Possible that a healing function out of the core is initiating these triggers, but does not differentiate between permanent powered and most of the time sleeping, battery powered devices.

previous log as part of #1442 170401: Inability to control any Z-wave devices Trying to switch of my lights yesterday evening, none of the devices responded to the Homey flows (devices were responsive with direct association).

I noticed several security commands send to my battery powered Fibaro Motion Sensor Plus devices (node 19 and 20)…

Z-wave log: 170401_Z-wave log.txt

manually waking up these devices cleared the lockup and devices became responsive again (never experienced this one pre-RC10)

Updated 20/04/2017 20:46 4 Comments

Battery drain

athombv/homey

What is your Homey version (Settings → System)? 1.2.0 rc9

What did you try to achieve? Yesterday almost all batteries were empty. Fibaro and Aeotec devices

What was the result? Some batteries went from 100% to 86 overnight.

What did you expect as result? That batteries don’t drain overnight.

Attached insight from the fibaro floodsensor 2017-03-24_09-54-11

Updated 04/04/2017 07:53

Z-Wave map goes berserk

athombv/homey

What is your Homey version (Settings → System)?

1.2.0 RC8

What did you try to achieve?

The Z-Wave topology map loads correctly, once loaded it starts spinning around like crazy and it seems it can’t stop forever. Have around 30 Z-Wave devices, this is insane. Not really noticeable on the picture, please see the video.

schermafbeelding 2017-03-20 om 19 23 44

https://www.youtube.com/watch?v=5o6mbDt4SoY

Issue, is active since the Z-Wave map has been implented

What was the result?

Can’t read Z-Wave map. Please note, there is a workaround to get the Z-Wave map to see: 1.full screen page, 2. Zoom out to a far maximum 3. grap one of the nodes and pull it away as far as possible (once dragged and moved The Z-wave map should come to a hold 4 Let go of the node and zoom back in, you should now have a good view.

What did you expect as result?

Working Z-Wave Map.

Updated 23/03/2017 16:14 4 Comments

Z-wave map: differentiate color of nodes with respect to routing capabilities

athombv/homey

What is your Homey version (Settings → System)? 1.1.9

Improvement proposal I see a lot of questions popping up regarding the z-wave map.

Is it possible to differentiate in node color on wether a node has routing capabilities (able to support the mesh) or not (e.g. battery powered devices without routing capability)?

And off coarse make Homey stand out more as controller.

Updated 23/02/2017 15:43

Exclude zwave mobile(items)/flows from view that are optional and not enabled

athombv/homey

What is your Homey version (Settings → System)?

1.1.2

The optional parameter in z-wave driver will ignore capabilities that are currently not available, but they will still be added to the mobile cards in the webif/mobile apps. While for a temperature sensor this is not that problematic, when other capabilities like onoff/dim/… this results in options in the mobile cards that are very confusing for end-users.

It would be nice if optional is specified and the capability is not available the items in mobile/flows will be excluded from the view. (Alternatively one could include an interface where you can disable devices/capabilities).

Updated 06/02/2017 12:50

Allow setting of optional in z-wave multiChannelNodes config

athombv/homey

What is your Homey version (Settings → System)?

1.1.2

What did you try to achieve?

Please include detailed steps how we can reproduce the issue

Some devices (Qubino shutter) allow setting a parameter that introduces a multi channel child device. Currently its not possible to include such device if the multi channel node is not available. Adding an option “optional: true” could fix this (similar like in zwave-driver).

Updated 16/03/2017 15:05 5 Comments

[Z-wave] Multi Channel association not possible (input validation NOK)

athombv/homey

What is your Homey version (Settings → System)? 1.1.2

What did you try to achieve? Add a multi channel end-point (Light connected to one of the Greenwave Powernode-6 sockets) node ID to the association group of a Fibaro Dimmer-2 (supporting COMMAND_CLASS_MULTI_CHANNEL and COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION) to switch on the light simultaneously with the light connected to the Dimmer-2

What was the result? Input validation of the association groups field does not accept non integer input (e.g. 10.1) to indicate the node ID of the multi channel end point (light connected to the greenwave powernode) <img width=“655” alt=“schermafbeelding 2017-01-21 om 10 45 31” src=“https://cloud.githubusercontent.com/assets/17163431/22173528/096a5f7a-dfc7-11e6-9c88-df6379bf4f6d.png”>

What did you expect as result? Able to add it to the association groups.

Has the COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION been fully implemented and is this only an input validation issue or is the COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION not (fully) implemented yet?

Any other remarks Work around is to create a flow within Homey to do this. But this is not the desired situation. Specifically in case of Z-wave sensors with alarm capability (e.g. motion or smoke sensors) it should be possible to directly switch on (or off) any other Z-wave devices by creating a direct association

In addition, new Z-wave Multi-channel sockets are currently under development by different parties…

Updated 13/03/2017 13:50 3 Comments

feature request: OTA firmware upgrade for ZWAVE devices

athombv/homey

What is your Homey version (Settings → System)?

1.0.4

What did you try to achieve?

I have several zwave devices that can get a firmware update Over The Air (OTA). E.g. the fibaro multisensor and the Aeotec multisensor. I only have a Homey as a controller, so I would very much like to be able to do the fw update using Homey! It would probably also solve a lot of device issues that users are experiencing with older device firmwares.

Please include detailed steps how we can reproduce the issue

What was the result?

What did you expect as result?

For Homey to support OTA zwave firmware updates.

Any other remarks

See for instance the information at:

https://aeotec.freshdesk.com/support/solutions/articles/6000036562-how-do-i-upgrade-the-firmware-for-multisensor-6-

https://forum.fibaro.com/index.php?/topic/21711-fibaro-device-firmware-list/

Updated 06/03/2017 13:55 11 Comments

Fork me on GitHub