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

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] Fibaro Motion Sensors do not switch on/off alarm

athombv/homey

What is your Homey version (Settings → System)?

Homey: 1.1.9

Fibaro: 1.2.2

What did you try to achieve?

After my Fibaro Motion Sensors (Z-Wave plus) have triggered a motion or tamper alarm, they sometimes keep the alarm on true although no motion or tamper has been triggered. Sometimes it is also the other way round, that the sensors do not trigger an alarm.

What was the result?

Motion and tamper alarm sometimes keep true although they should be false or are not beeing triggered. After some time they work correctly again.

What did you expect as result?

That the alarms go offline after the period, which has been set and that the motion sensors are beeing triggered at all.

Any other remarks

If I check out the Z-wave log, I see that Homey still receives data from the faulty working sensors in both cases. I can provide the logs if someone is interessted.

Updated 14/03/2017 18:10 7 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

[1.1.2] Z-wave debugging + device pairing: many "Error: queue_full" messages

athombv/homey

What is your Homey version (Settings → System)?

1.1.2

What did you try to achieve? Debugging issues with a Z-wave app (Neo in this case). While going through the debug logging, I do see a lot of “Error: queue_full” messages blocking transmission / reporting of data.

Some examples

[debug] COMMAND_CLASS_SENSOR_MULTILEVEL SENSOR_MULTILEVEL_GET args: { ‘Sensor Type’: ‘Luminance (version 1)’, Properties1: { Scale: 1 } } err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] COMMAND_CLASS_SENSOR_MULTILEVEL SENSOR_MULTILEVEL_GET args: { ‘Sensor Type’: ‘Luminance (version 1)’, Properties1: { Scale: 1 } } err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] node.on(‘online’) arguments: { ‘0’: true }

[debug] COMMAND_CLASS_SENSOR_MULTILEVEL SENSOR_MULTILEVEL_GET args: { ‘Sensor Type’: ‘Luminance (version 1)’, Properties1: { Scale: 1 } } err: { [Error: timeout] message: ‘timeout’ } result: null [debug] COMMAND_CLASS_BATTERY BATTERY_GET args: {} err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] node.on(‘online’) arguments: { ‘0’: false } [debug] node.on(‘online’) arguments: { ‘0’: false }

[debug] get alarm_motion [debug] get measure_luminance [debug] get measure_battery [debug] COMMAND_CLASS_SENSOR_MULTILEVEL SENSOR_MULTILEVEL_GET args: { ‘Sensor Type’: ‘Luminance (version 1)’, Properties1: { Scale: 1 } } err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] COMMAND_CLASS_BATTERY BATTERY_GET args: {} err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] COMMAND_CLASS_BATTERY BATTERY_GET args: {} err: { [Error: queue_full] message: ‘queue_full’ } result: null [debug] node.on(‘online’) arguments: { ‘0’: false } [debug] node.on(‘online’) arguments: { ‘0’: true } [debug] COMMAND_CLASS_BATTERY->BATTERY_GET args: {} cb: true

Any other remarks It is for me unclear which queue is referred to, yet I assume that this is the Z-wave command queue which possibly has been updated to resolve the ProcessSendData issue

Updated 14/03/2017 18:08 8 Comments

Danfoss / Devolo battery controlled TRV: E5 back again (from v1.0.3+)

athombv/homey

What is your Homey version (Settings → System)?

1.0.4

What did you try to achieve?

Use the Danfoss/Devolo TRV without the E5 issue.

What was the result?

On 1.0.2 the device was working perfectly. Very responsive when pressing a button on the device also and a rock solid bell + wireless icon. This was after the WAKEUP_NO_MORE_INFORMATION was implemented into the firmware. In the Devolo App I still use the pollIntervall as suggested by Robin.

On 1.0.3 according to the release notes something was changed in the WAKEUP_NO_MORE_INFORMATION implementation. I think I saw that also in the logging of the App as it seemed that all potentially possible command classes were polled. Additionally it had impact in the device. Because when pressing a button on it (like + or -) it now took a long time for the display to respond and the bell + wireless icons were blinking indicating an error in the communication!

Now after a while I’m getting the E5 error back again.

So in my mind something was changed between 1.0.2 and 1.03 and upwards impacting the WAKEUP_NO_MORE_INFORMATION implementation which leads to the device going into error mode again.

What did you expect as result?

Can you please have a look into the changes between 1.0.2 and 1.0.3 and upwards regarding the communication with battery operated devices?

Updated 14/03/2017 19:03 9 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