zwave-js / zwave-js-ui Goto Github PK

Nodes values should be grouped In sections and command classes

Version

Build/Run method

• [ X ] Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha.0

Describe the bug
1.) The Network Key auto-generation (I'm assuming that is what the recycle symbol to the right is) did not do anything in Firefox
2.) If the user enters a Network key that is "3DMM7Z359G253QL0OHK1F2TUGT3IEKD5" there is an error generated that is only visible if you are attached to the docker image and watching the logs

z2m:App POST /api/settings 200 48.092 ms - 63 +8m
This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
ZWaveError: The network key must be a buffer with length 16!
    at checkOptions (/usr/src/app/node_modules/zwave-js/src/lib/driver/Driver.ts:267:9)
    at new Driver (/usr/src/app/node_modules/zwave-js/src/lib/driver/Driver.ts:452:3)
    at ZwaveClient.connect (/usr/src/app/lib/ZwaveClient.js:1301:19)
    at Gateway.start (/usr/src/app/lib/Gateway.js:164:16)
    at startGateway (/usr/src/app/app.js:56:6)
    at /usr/src/app/app.js:285:5
  z2m:Mqtt MQTT client connected +79ms

To Reproduce
Steps to reproduce the behavior:

1. Create brand new docker image
2. Set up zwave with network key '3DMM7Z359G253QL0OHK1F2TUGT3IEKD5'
3. Ensure you are attached to the docker image via SSH
4. See error

Expected behavior
Errors should be made available to the user via the user interface to alert them there is a problem.

Additional context
I realize I had a bad network key :)

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: I'm not sure how to get this. I'm using zwavejs/zwavejs2mqtt:dev pulled on 24th Dec

Describe the bug
Autodiscovered devices for Greeenwave PowerNode 6-plugs are using wrong topics
Manufacturer ID: 153
Product Type: 3
Product ID: 4

• kwh_meter sensors unit_of_measurement should be kWh, not seconds. The point out to [node]/X/deltaTime/65537 instead to [node]/X/value/65537 (with X=1 to 6)
• w_meter sensors unit_of_measurement should be W, not seconds. They point out to [node]/X/deltaTime/66049 instead to [node]/X/value/66049 (with X=1 to 6)

I'm pretty confident in earlier versions of ZWaveJS2MQTT the autodiscovered devices were right (kwh sensors pointed out towards the right kwh topics, the same with the "w". In fact, even "previous value" and "delta time" devices were autodiscovered (and they don't now) so I'm not sure if this could be some kind of regression.

I've tried "rediscovering" the node and also "Refreshing Node Info" with no luck. For now, you need to edit the HASS device JSON and set the proper proper topics manually.

Version
Build/Run method

• [ X ] Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha

Describe the bug
When my Aeotec door sensor reports a notification that the door is open, no MQTT message appears to be generated.

To Reproduce
Steps to reproduce the behavior:

1. Add Aeotec Door Sensor 7
2. Open door, observe debug log message come in "INFO ZWAVE: Node 17: value updated: 113-0-Access Control-Door state", while monitoring MQTT Explorer you will see no MQTT message generated.

Expected behavior
If 113-0-Access Control-Door State is changed I would expect an MQTT message to be produced.

Additional context
This may be partially related to #91, because originally the door notification would not be discovered. So I manually modified the payload to allow for discovery. It was only then that I figured out that the mqtt message for the door opening also didn't seem to be being generated. However I may be misunderstanding how this works. Let me know if I can provide more information.
When I monitor the 133->0 topics I only see "Power_Management" and "System". "Access Control" never appears.

as discussed in zwave-js/node-zwave-js#1125

Is your feature request related to a problem? Please describe.
When I need to provide debug logs to debug an issue, I need to enable logging and bump up the log level to debug. When I hit "save" the zwave network restarts and we need do interview all nodes again. This takes a while.

Describe the solution you'd like
It would be great if I could enable and disable logging, and change loglevel without the entire network being restarted.

Describe alternatives you've considered
Keeping debug logging on all the time. But this creates big files.

• Fix hass discovery: everything is using valueId index, need to support the new property/propertyKey, also some valueIds use different topics for read/write (like currentValue and targetValue)
• Docs: general docs fix
• Scenes
• Zwave events
• Basic MQTT Gateway and Control Panel functions
• Docker setup
• Rgb colors management: zwave-js/node-zwave-js#806
• Move to winston/pino logger

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: v1.0.0-alpha.1

Using tag latest so I'm not sure the exact build.

Describe the bug
For a climate device, the control panel is not displaying the "Operating state" text value (Heating, Cooling, etc), instead it is an integer. Compare that with the "Thermostat mode" which does display the text.

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Control Panel'
2. Click on a thermostat node
3. Scroll down to 'User Values' and expand
4. Observe the thermostat operating state

Expected behavior
Instead of the numerical value, e.g. 1, it should display the text, e.g. Heating. This would be consistent with mode, and more user friendly.

Additional context
I've setup the MQTT gateway with type ValueID topics and payload entire z-wave object. Here is the payload for the operating state value. As you can see, the text values are available, the same way as the thermostat mode is.

topic: z2m/5/66/1/state
payload:

json
{
  "id": "5-66-1-state",
  "nodeId": 5,
  "commandClass": 66,
  "commandClassName": "Thermostat Operating State",
  "endpoint": 1,
  "property": "state",
  "propertyName": "state",
  "type": "number",
  "readable": true,
  "writeable": false,
  "label": "Operating state",
  "genre": "user",
  "min": 0,
  "max": 255,
  "list": true,
  "states": [
    {
      "text": "Idle",
      "value": 0
    },
    {
      "text": "Heating",
      "value": 1
    },
    {
      "text": "Cooling",
      "value": 2
    },
    {
      "text": "Fan Only",
      "value": 3
    },
    {
      "text": "Pending Heat",
      "value": 4
    },
    {
      "text": "Pending Cool",
      "value": 5
    },
    {
      "text": "Vent/Economizer",
      "value": 6
    },
    {
      "text": "Aux Heating",
      "value": 7
    },
    {
      "text": "2nd Stage Heating",
      "value": 8
    },
    {
      "text": "2nd Stage Cooling",
      "value": 9
    },
    {
      "text": "2nd Stage Aux Heat",
      "value": 10
    },
    {
      "text": "3rd Stage Aux Heat",
      "value": 11
    }
  ],
  "value": 1,
  "lastUpdate": 1608134706720
}

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
When I try to update Aeotec Smart Switch 6 ZW096 with firmware downloaded from Aeotec n .hec format, I get the error message:

Error while calling api beginFirmwareUpdate: Unable to extract firmware from file: could not detect firmware format

Describe the solution you'd like
Correctly detecting the format and converting it to a usable format, and begin FW upgrade process.

Describe alternatives you've considered
None.

Additional context
EU firmware downloaded from link at the bottom of this page:
https://aeotec.freshdesk.com/support/solutions/articles/6000205150-update-smart-switch-6-firmware-via-homeseer-

Hi :),

Running the NPM way 3th december master (no more links to the node-zwave-js project)

Well i've got a new device (According to gateway webpage):
ThermoFloor | Wall Mounted Switch | Heatit Z Push Button 8

I want to create an association but it is not working, because the z wave software states that the device is asleep:
zwavejs2mqtt/landing_buttons/status is {"time":1607006651989,"value":true,"status":"Asleep"}

I see that the message is put into a queue:
[REQ] SendData (SecurityCCCommandEncapsulation) [Node 18, asleep]

Since it is a battery device i know that it needs to be woken before sending associations, which i do.
When i do that i see a new central scene updated on mqtt, so it should be awake, but the status stays asleep in the topic, even after receiving the central scene, and the queue is not send to the device.

According to the manual of the device it stays awake for 30 seconds after the button was pressed.

I send multiple times using the gateway webpage the association, and pressed multiple time a button on the device.

Console: zwave-5945-console.log
See logs: zwave-5945.log

Thnx!

zwavejs2mqtt version: hass#discovery - lastest

My Aeotec ZW164 is a sound switch device (I would say). Many executeable commands under CC 121 (sound switch) are showing under system tab and not user or config.

Can this be corrected somehow?
Attached a screen shot, used a tool to capture while scrolling

Is there a recommended or "easy" migration path from zwave2mqtt to zwavejs2mqtt? I'm very interested in getting more of my system moved to javascript and hopefully leaving behind the bug which is making my setup struggle.

Thanks! I'm excited for this project!

Hi,

So,,, you've asked to keep testing,,, apparently i ran into a new issue.
Still running the latest dev container.

Only seen once, when sending a scene while zwave-js is still resuming from cache:

This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). The promise rejected with the reason:
ZWaveError: Timed out while waiting for a response from the node
    at Object.sendDataErrorToZWaveError (/usr/src/app/node_modules/zwave-js/src/lib/driver/StateMachineShared.ts:147:11)
    at /usr/src/app/node_modules/zwave-js/src/lib/driver/SendThreadMachine.ts:432:4
    at /usr/src/app/node_modules/xstate/lib/utils.js:409:33
    at Array.reduce (<anonymous>)
    at Object.updateContext (/usr/src/app/node_modules/xstate/lib/utils.js:399:25)
    at Object.resolveActions (/usr/src/app/node_modules/xstate/lib/actions.js:405:19)
    at StateNode.resolveTransition (/usr/src/app/node_modules/xstate/lib/StateNode.js:787:35)
    at StateNode.transition (/usr/src/app/node_modules/xstate/lib/StateNode.js:733:21)
    at /usr/src/app/node_modules/xstate/lib/interpreter.js:600:34
    at Object.exports.provide (/usr/src/app/node_modules/xstate/lib/serviceScope.js:11:18)
    at Interpreter.nextState (/usr/src/app/node_modules/xstate/lib/interpreter.js:599:38)
    at /usr/src/app/node_modules/xstate/lib/interpreter.js:124:39
    at Scheduler.process (/usr/src/app/node_modules/xstate/lib/scheduler.js:60:13)
    at Scheduler.schedule (/usr/src/app/node_modules/xstate/lib/scheduler.js:44:14)
    at Interpreter.send (/usr/src/app/node_modules/xstate/lib/interpreter.js:121:29)
    at Timeout.<anonymous> (/usr/src/app/node_modules/xstate/lib/interpreter.js:631:23)

I guess when resuming from cache the network is pretty busy and not able to reach this node.
At least it should be handled.

I don't see strange things in the zwave-1 log file
zwave-1.log

Thnx!

podman run --rm -it -p 8091:8091 --device=/dev/ttyACM0 -v zwave-js:/usr/src/app/store zwavejs/zwavejs2mqtt:dev

Results in an error:
Error: Cannot find module 'semver'

Workaround for me was to rebuild the image and add the semver package:

FROM docker.io/zwavejs/zwavejs2mqtt:dev
RUN /usr/local/bin/npm install semver

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.2.3

Describe the bug
The Aeotec Water Sensor 6 is detected as the correct model and some sensors setup, but the two binary sensors are not discovered by HA for the two water probes (using the dock). This worked correctly in 1.6.

The two notification classes are detected and sent to mqtt:

When clear (value:0):

{
   "id":"130-113-1-Water Alarm-Sensor status",
   "nodeId":130,
   "commandClass":113,
   "commandClassName":"Notification",
   "endpoint":1,
   "property":"Water Alarm",
   "propertyName":"Water Alarm",
   "propertyKey":"Sensor status",
   "type":"number",
   "readable":true,
   "writeable":false,
   "label":"Sensor status",
   "ccSpecific":{
      "notificationType":5
   },
   "min":0,
   "max":255,
   "list":true,
   "states":[
      {
         "text":"idle",
         "value":0
      },
      {
         "text":"Water leak detected",
         "value":2
      }
   ],
   "value":0,
   "lastUpdate":1609220737810
}

When water is detected (value:2):

{
   "id":"130-113-1-Water Alarm-Sensor status",
   "nodeId":130,
   "commandClass":113,
   "commandClassName":"Notification",
   "endpoint":1,
   "property":"Water Alarm",
   "propertyName":"Water Alarm",
   "propertyKey":"Sensor status",
   "type":"number",
   "readable":true,
   "writeable":false,
   "label":"Sensor status",
   "ccSpecific":{
      "notificationType":5
   },
   "min":0,
   "max":255,
   "list":true,
   "states":[
      {
         "text":"idle",
         "value":0
      },
      {
         "text":"Water leak detected",
         "value":2
      }
   ],
   "value":2,
   "lastUpdate":1609220736395
}

But binary sensors are not created:

Here is the ozw 1.6 device file: https://github.com/OpenZWave/open-zwave/blob/master/config/aeotec/zw122.xml

I have several of these and they are all the same.

To Reproduce
Steps to reproduce the behavior:

1. Pair sensor

Expected behavior
Two binary_sensors should be created reflecting the notification command class.

Additional context

Here is the log file during a trip of one of the water sensors:

05:45:36.112 DRIVER « [Node 130] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 1
                        └─[NotificationCCReport]
                            notification type:   Water Alarm
                            notification status: 255
                            notification state:  Water leak detected
05:45:36.117 CNTRLR   [Node 130] [+] [Notification] Water Alarm[Sensor status]: 2       [Endpoint 1]
05:45:36.330 SERIAL « 0x0114000400820e600d01017105000000ff0502000082                      (22 bytes)
05:45:36.331 SERIAL » [ACK]                                                                   (0x06)
05:45:36.332 DRIVER « [Node 130] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 1
                        └─[NotificationCCReport]
                            notification type:   Water Alarm
                            notification status: 255
                            notification state:  Water leak detected
05:45:36.334 CNTRLR   [Node 130] [~] [Notification] Water Alarm[Sensor status]: 2 => 2  [Endpoint 1]
05:45:36.390 SERIAL « 0x0114000400820e600d01007105000000ff0502000083                      (22 bytes)
05:45:36.391 SERIAL » [ACK]                                                                   (0x06)
05:45:36.393 DRIVER « [Node 130] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 0
                        └─[NotificationCCReport]
                            notification type:   Water Alarm
                            notification status: 255
                            notification state:  Water leak detected
05:45:36.394 CNTRLR   [Node 130] [~] [Notification] Water Alarm[Sensor status]: 2 => 2  [Endpoint 1]
05:45:37.739 SERIAL « 0x0114000400820e600d01017105000000ff0500000080                      (22 bytes)
05:45:37.741 SERIAL » [ACK]                                                                   (0x06)
05:45:37.743 DRIVER « [Node 130] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 1
                        └─[NotificationCCReport]
                            notification type:   Water Alarm
                            notification status: 255
                            notification event:  Unknown (0x00)
05:45:37.809 CNTRLR   [Node 130] [~] [Notification] Water Alarm[Sensor status]: 2 => 0  [Endpoint 1]
05:45:37.823 SERIAL « 0x0114000400820e600d01007105000000ff0500000081                      (22 bytes)
05:45:37.824 SERIAL » [ACK]                                                                   (0x06)
05:45:37.828 DRIVER « [Node 130] [REQ] [ApplicationCommand]
                      └─[MultiChannelCCCommandEncapsulation]
                        │ source:      1
                        │ destination: 0
                        └─[NotificationCCReport]
                            notification type:   Water Alarm
                            notification status: 255
                            notification event:  Unknown (0x00)

Hi,

Well, i got this message in the log podman-zwave.log

2020-11-24T15:47:32.534Z z2m:Zwave Error while writing 0 on 7-38-1-targetValue: Timed out while waiting for a response from the node
2020-11-24T15:47:32.535Z z2m:Zwave Unable to write 0 on 7-38-1-targetValue

How-ever the command was received since the node 007 (I should call that one James i guess) did close the shutter.

And i looks like the command send is also logged:
zwave-1.log

15:47:30.894 DRIVER » [Node 007] [REQ] [SendData]
                      │ transmit options: 0x25
                      │ callback id:      62
                      └─[SecurityCCCommandEncapsulation]
                        │ nonce id: 138
                        └─[MultiChannelCCCommandEncapsulation]
                          │ source:      0
                          │ destination: 1
                          └─[SupervisionCCGet]
                            │ session id:      32
                            │ request updates: true
                            └─[MultilevelSwitchCCSet]
                                target value: 0

As you can see in the log i did send value 0 to 12 nodes at the same time (in there own topic).

The issue is now from mqtt perspective (and the management website) the current value is still 99 but it is physically closed.
Node 7 is "bathroom" but node 6 "study" has the same issue, also in that log.

Thnx again, keep up the good work!

Lets eat all this small snacks , you guys created something nice!

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.2.3

Describe the bug
Upon a first-time install of the current docker image the docker image cannot start (either with docker-compose or just docker). It exits with the following error:

|___ / () |__ \ | | | |
/ / ____ ___ _____ _ ___ ) |_ __ ___ __ | || |_
/ /\ \ /\ / / \ \ / / _ \ / __| / /| '_ _ \ / ` | __| |
/ /\ V V / (| |\ V / _/ _ / /| | | | | | (| | || |_
/|_/_/ _,| _/ _| |/|| || ||_, |_|_|
/ | | |
|__/ ||

2020-12-28 21:04:46.146 WARN STORE: settings.json not found
2020-12-28 21:04:46.212 WARN STORE: scenes.json not found
2020-12-28 21:04:46.213 WARN STORE: nodes.json not found
/bin/sh: git: not found
2020-12-28 21:04:47.835 INFO APP: Version: 1.0.0-alpha.1
2020-12-28 21:04:47.836 INFO APP: Application path:/usr/src/app
TypeError: Cannot read property 'logEnabled' of undefined
at setupLogging (/usr/src/app/app.js:43:31)
at startGateway (/usr/src/app/app.js:56:3)
at start (/usr/src/app/app.js:38:3)
at /usr/src/app/bin/www:98:5
at tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
at Promise._settlePromiseFromHandler (/usr/src/app/node_modules/bluebird/js/release/promise.js:547:31)
at Promise._settlePromise (/usr/src/app/node_modules/bluebird/js/release/promise.js:604:18)
at Promise._settlePromise0 (/usr/src/app/node_modules/bluebird/js/release/promise.js:649:10)
at Promise._settlePromises (/usr/src/app/node_modules/bluebird/js/release/promise.js:729:18)
at _drainQueueStep (/usr/src/app/node_modules/bluebird/js/release/async.js:93:12)
at _drainQueue (/usr/src/app/node_modules/bluebird/js/release/async.js:86:9)
at Async._drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:102:5)
at Immediate.Async.drainQueues [as _onImmediate] (/usr/src/app/node_modules/bluebird/js/release/async.js:15:14)
at processImmediate (internal/timers.js:461:21)

To Reproduce
Steps to reproduce the behavior:

1. Pull docker image
2. Start the image using "docker run --rm -it -p 8091:8091 --device=/dev/ttyACM0 --mount source=zwavejs2mqtt,target=/usr/src/app/store zwavejs/zwavejs2mqtt:latest"
3. Error

Expected behavior
The docker image should start...

Additional context
Docker version: 20.10.1, build 831ebea
OS: Raspbian, 32 bit (armv7l)

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: latest Master

When you .first start the application. A first discovery is generated by the app. On Binary switches this looks like:

{
  "type": "switch",
  "object_id": "switch",
  "discovery_payload": {
    "payload_off": false,
    "payload_on": true,
    "value_template": "{{ value_json.value }}",
    "command_topic": "zwave2mqtt/Guestroom/switch/37/1/currentValue/set",
    "state_topic": "zwave2mqtt/Guestroom/switch/37/1/currentValue",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xcddb486e_node66"
      ],
      "manufacturer": "Fibargroup",
      "model": "Single Switch 2 (FGS213)",
      "name": "Guestroom-switch",
      "sw_version": "3.3"
    },
    "name": "Guestroom-switch_switch",
    "unique_id": "zwavejs2mqtt_0xcddb486e_66-37-1-currentValue"
  },
  "discoveryTopic": "switch/Guestroom-switch/switch/config",
  "values": [
    "37-1-currentValue",
    "37-1-targetValue"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "switch_switch"
}

As we can see commandTopic is wrong, as currentValue is read only, and does not accept set commands
Once we click rediscover node we get the right payload:

{
  "type": "switch",
  "object_id": "switch",
  "discovery_payload": {
    "payload_off": false,
    "payload_on": true,
    "value_template": "{{ value_json.value }}",
    "command_topic": "zwave2mqtt/Guestroom/switch/37/1/targetValue/set",
    "state_topic": "zwave2mqtt/Guestroom/switch/37/1/currentValue",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xcddb486e_node66"
      ],
      "manufacturer": "Fibargroup",
      "model": "Single Switch 2 (FGS213)",
      "name": "Guestroom-switch",
      "sw_version": "3.3"
    },
    "name": "Guestroom-switch_switch",
    "unique_id": "zwavejs2mqtt_0xcddb486e_66-37-1-currentValue"
  },
  "discoveryTopic": "switch/Guestroom-switch/switch/config",
  "values": [
    "37-1-currentValue",
    "37-1-targetValue"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "switch_switch"
}

I tried to add at lib/Gateway.js line 1320 the following:

cfg.discovery_payload.command_topic = setTopic

Which converts the command_topic on first startup/restart to null.
The strange part is values contain Target Value. I tried to find where in code this can be causing it. But still I have no clue.

Is your feature request related to a problem? Please describe.
Greenwave sockets have an annoying feature where the LED on the socket starts blinking after a configurable time of inactivity. The highest value you can set this to is however 255 minutes (setting 112-0-1). For sockets that are not used that much or for instance at night this blinking occurs after this time. To avoid the LED from blinking communication between the controller is needed. On zwave2mqtt there was a user setting that you could set to "Disable" for instance every 4 hours to make sure the blinking does not occur. The setting didnt do anything else, it would automatically update to enable again so you could just send disable every 4 hours and that would avoid the LED for starting to blink. The setting in zwave2mqtt was 112-1-4.

I do see a setting under config within zwavejs2mqtt called LED for network error (122-0-4) which seems to be the same setting. Setting this from the UI however does not stop the light from blinking. It looks like it's not actually being saved and I'm not seeying anything being published to MQTT either. And I dont know how to set this setting through MQTT. On zwave2mqtt I published a payload "Disable" to 112-1-4-set every 4 hours but publish this to 112-0-4-targetValue-set doesnt work. So i'd appreciate if this could be fixed somehow so my LEDs dont start blinking at night. Below are the ID's of the Greenwave products I'm talking about.

• Single socket: 153-2-2 (0x0099-0x0002-0x0002)
• multi socket brick: 153-4-3 (0x0099-0x0004-0x0003)

Is there a way to speficy the location of the log file? @AlCalzone

Ref: #22 (comment)

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: master

When saving the configuration on zwavejs2mqtt web interface process exits

running npm with trace-exit

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:208:20)
18:27:41.267 DRIVER   destroying driver instance...
18:27:41.269 DRIVER   destroying driver instance...
18:27:41.270 DRIVER   destroying driver instance...
(node:66) WARNING: Exited the environment with code 1
    at exit (internal/process/per_thread.js:172:13)
    at /usr/src/app/node_modules/@sentry/node/dist/handlers.js:231:24
    at onfulfilled (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:138:33)
    at /usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:67:33
    at SyncPromise._executeHandlers (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:60:28)
    at SyncPromise._setResult (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:45:19)
    at SyncPromise._resolve (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:28:19)
    at onfulfilled (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:138:25)
    at /usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:67:33
    at SyncPromise._executeHandlers (/usr/src/app/node_modules/@sentry/utils/dist/syncpromise.js:60:28)
/usr/src/app #zwavejs2mqtt 

i receive as error

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: I'm not sure how to get this. I'm using zwavejs/zwavejs2mqtt:dev pulled on 21st Dec

Describe the bug
ZwaveJS2MQTT is not updating the motion information (topic 48-0-Any) for the Fibaro FGMS001 motion sensor.

If I understand properly, for this device ZwaveJS2MQTT idenfity a contact device with topic 48-1-0. It should be a binary_sensor with value True if there is motion and False if there is no motion.

Unfortunately, although the sensor detects a motion event (led is on in the physical device; you can also see it in the screenshots below at topics with CC 113), the state of the 48-0-Any topic remains on the state which it intially has when pairing the device.

No motion:

Motion:

To Reproduce
Steps to reproduce the behavior:
Pair a Fibaro FGMS001 motion sensor
Trigger a motion event
Check your MQTT broker if the value of the 48-0-Any topic is updated.

Expected behavior
Having the topic for this sensor updated in correspondence of the motion events. That way you could have a HASS binary_sensor for presence.

Additional context
This seems to be exactly the same issue reported in OpenZWave/Zwave2Mqtt#621 for the Zwave2MQTT project.
In that project the root cause pointed out towards an issue at OZW implementation. Apparently to OpenZWave/open-zwave#2300
Just in case the comments on it helps here somehow (I don't understand the final conclusion of that case)

Version
master

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

Describe the bug
When the network key field is empty, and you click the generate key button, it doesn't work. If you manually put in a key, save, and then try to regenerate the key, it works.

To Reproduce
Steps to reproduce the behavior:

1. Have empty network key field, also in settings.json
2. Click on generate key button
3. No key is being put in the field

Expected behavior
A key being put in the field.

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.2.3

Describe the bug

GE dimmer/switches are capable of double tap events. In zwave2mqtt these show as events under the node, with 255 indicating double tap up and 0 indicating double tap down. (My ozw device files were set to ignore the command mapping for class 32 from qt-openzwave and I carried this over when I switched so I don't know if it was necessary.

These are the steps to make it work under qt-openzwave: https://community.home-assistant.io/t/howto-add-double-tap-support-for-ge-switches-and-dimmers-in-ozw-beta/228871/16.

The original qt-openzwave issue which has more detailed info is at: OpenZWave/qt-openzwave#60.

Double tap up in zwavejs2mqtt now shows:

zwavejs2mqtt    | 2020-12-28 23:32:24.898 INFO ZWAVE: Node 3: value updated: 38-0-currentValue 50 => 255

(The current value goes to 255 and HA thinks the device is now at 100%, but the physical dim has not changed. They are now out of sync.)

Both regular down and double-tap down show 0 so I don't see a way to differentiate those:

zwavejs2mqtt | 2020-12-28 23:21:25.052 INFO ZWAVE: Node 3: value updated: 38-0-currentValue 50 => 0

To Reproduce
Steps to reproduce the behavior:

1. Double click up, or double click down

Expected behavior
Double tap up should generate an mqtt event or message that can be acted upon, if not a sensor within HA. In zwave2mqtt I just subscribed to the topic in Appdaemon.

Additional context
Add any other context about the problem here.

While attempting to run the platform via docker, the following message is printed out:

root@klemen-VirtualBox:/home/klemen# docker run --rm -it -p 8091:8091 --device=/dev/ttyS0 --mount source=zwavejs2mqtt,target=/usr/src/app/store zwavejs/zwavejs2mqtt:latest
Unable to find image 'zwavejs/zwavejs2mqtt:latest' locally
docker: Error response from daemon: manifest for zwavejs/zwavejs2mqtt:latest not found: manifest unknown: manifest unknown.
See 'docker run --help'.

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha.1 from log, Docker is dev tag in place 12/28
HA: Hassio 2020.12.1

Describe the bug
Auto-discovery on HA finds the device and battery sensor but misses the door open/close sensor, and cover open/close sensor.

To Reproduce
Steps to reproduce the behavior:

1. Setup HA to auto-discover MQTT
2. Add node to ZWave network

Expected behavior
The device has 3 sensors. Expect all 3 of them to appear in HA. Only the battery sensor is discovered.

Additional context
JSON of node info:

	{
		"name": "Small_Bedroom_Closet_Door",
		"hassDevices": {
			"sensor_notification_Access Control": {
				"type": "sensor",
				"object_id": "notification_Access Control",
				"discovery_payload": {
					"value_template": "{{ value_json.value }}",
					"icon": "mdi:alarm-light",
					"state_topic": "homeassistant/Small_Bedroom_Closet_Door/113/0/Access_Control/Door_state",
					"json_attributes_topic": "homeassistant/Small_Bedroom_Closet_Door/113/0/Access_Control/Door_state",
					"device": {
						"identifiers": [
							"zwavejs2mqtt_0xc3c70e48_node6"
						],
						"manufacturer": "HANK Electronics Ltd.",
						"model": "Door and Window Sensor (DWS01)",
						"name": "Small_Bedroom_Closet_Door",
						"sw_version": "1.5"
					},
					"name": "Small_Bedroom_Closet_Door_notification_Access Control",
					"unique_id": "zwavejs2mqtt_0xc3c70e48_6-113-0-Access Control-Door state"
				},
				"discoveryTopic": "sensor/Small_Bedroom_Closet_Door/notification_Access Control/config",
				"values": [
					"113-0-Access Control-Door state"
				],
				"persistent": true,
				"ignoreDiscovery": false
			},
			"sensor_notification_Home Security": {
				"type": "sensor",
				"object_id": "notification_Home Security",
				"discovery_payload": {
					"value_template": "{{ value_json.value }}",
					"icon": "mdi:alarm-light",
					"state_topic": "homeassistant/Small_Bedroom_Closet_Door/113/0/Home_Security/Cover_status",
					"json_attributes_topic": "homeassistant/Small_Bedroom_Closet_Door/113/0/Home_Security/Cover_status",
					"device": {
						"identifiers": [
							"zwavejs2mqtt_0xc3c70e48_node6"
						],
						"manufacturer": "HANK Electronics Ltd.",
						"model": "Door and Window Sensor (DWS01)",
						"name": "Small_Bedroom_Closet_Door",
						"sw_version": "1.5"
					},
					"name": "Small_Bedroom_Closet_Door_notification_Home Security",
					"unique_id": "zwavejs2mqtt_0xc3c70e48_6-113-0-Home Security-Cover status"
				},
				"discoveryTopic": "sensor/Small_Bedroom_Closet_Door/notification_Home Security/config",
				"values": [
					"113-0-Home Security-Cover status"
				],
				"persistent": true,
				"ignoreDiscovery": false
			},
			"sensor_battery_level": {
				"type": "sensor",
				"object_id": "battery_level",
				"discovery_payload": {
					"value_template": "{{ value_json.value }}",
					"device_class": "battery",
					"unit_of_measurement": "%",
					"state_topic": "homeassistant/Small_Bedroom_Closet_Door/128/0/level",
					"json_attributes_topic": "homeassistant/Small_Bedroom_Closet_Door/128/0/level",
					"device": {
						"identifiers": [
							"zwavejs2mqtt_0xc3c70e48_node6"
						],
						"manufacturer": "HANK Electronics Ltd.",
						"model": "Door and Window Sensor (DWS01)",
						"name": "Small_Bedroom_Closet_Door",
						"sw_version": "1.5"
					},
					"name": "Small_Bedroom_Closet_Door_battery_level",
					"unique_id": "zwavejs2mqtt_0xc3c70e48_6-128-0-level"
				},
				"discoveryTopic": "sensor/Small_Bedroom_Closet_Door/battery_level/config",
				"values": [
					"128-0-level"
				],
				"persistent": true,
				"ignoreDiscovery": false
			}
		}
	}

I am trying out Zwavejs2mqtt and thought that this time I'd try Type: "Named Topics" in the Gateway.

It worked find for sending data to Home Assistant, but when I tried to send commands (like toggling a switch) I could see the commands being received in the console output (I am attached to the docker container and I would set "z2m:Mqtt: Message received on zwavJs2Mqtt/Patio/Shades_Ext_South_West/switch_multilevel/targeValue/set"), but no Z-wave commands would be sent and the device would not operate.

I then changed my Type to "ValueID topics" and the commands were now being received ("z2m:Mqtt: Message received on zwaveJs2Mqtt/Patio/5/38/0/targetValue/set"), and the Z-wave commands would be sent and the device responded.

I'm not sure if I was doing something wrong, or if I should be using ValueID instead of Named, but I figured I'd let you know that Named wasn't working for inbound messages from Home Assistant for me.

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: master

Describe the bug
Some devices create 113-0-Home_Security-Motion_sensor_status and 113-0-Home_Security-Cover_status values. Hass discovery creates sensor_notification_Home_Security for motion and sensor_notification_Home_Security_Home Security for cover. These names could be better represented. Maybe as sensor_notification_home_security_motion and sensor_notification_home_security_cover or something in those lines. I'm not sure what the appropriate name should be. I can look at what z2m/ozw creates and post them here for reference.

The other issue is that the payload also has those names and they're not good names. They should also be improved:
Motion sensor:

{
  "type": "sensor",
  "object_id": "notification_Home Security",
  "discovery_payload": {
    "value_template": "{{ value_json.value }}",
    "icon": "mdi:alarm-light",
    "state_topic": "z2m/24/113/0/Home_Security/Motion_sensor_status",
    "json_attributes_topic": "z2m/24/113/0/Home_Security/Motion_sensor_status",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc5b5c9e5_node24"
      ],
      "manufacturer": "Vision Security",
      "model": "Zooz 4-in-one motion/temperature/humidity/luminance sensor (ZSE40)",
      "name": "master",
      "sw_version": "5.1"
    },
    "name": "master_notification_Home Security",
    "unique_id": "zwavejs2mqtt_0xc5b5c9e5_24-113-0-Home Security-Motion sensor status"
  },
  "discoveryTopic": "sensor/master/notification_Home Security/config",
  "values": [
    "113-0-Home Security-Motion sensor status"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_notification_Home Security"
}

Cover sensor:

{
  "type": "sensor",
  "object_id": "notification_Home Security_Home Security",
  "discovery_payload": {
    "value_template": "{{ value_json.value }}",
    "icon": "mdi:alarm-light",
    "state_topic": "z2m/24/113/0/Home_Security/Cover_status",
    "json_attributes_topic": "z2m/24/113/0/Home_Security/Cover_status",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xc5b5c9e5_node24"
      ],
      "manufacturer": "Vision Security",
      "model": "Zooz 4-in-one motion/temperature/humidity/luminance sensor (ZSE40)",
      "name": "master",
      "sw_version": "5.1"
    },
    "name": "master_notification_Home Security_Home Security",
    "unique_id": "zwavejs2mqtt_0xc5b5c9e5_24-113-0-Home Security-Cover status"
  },
  "discoveryTopic": "sensor/master/notification_Home Security_Home Security/config",
  "values": [
    "113-0-Home Security-Cover status"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_notification_Home Security_Home Security"
}

The other thing is that both the motion and cover sensors don't show up in Hass. I haven't seen any errors in the logs in Hass. I'll keep digging.

Version

Build/Run method

• [ x ] Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 0.0.0 latest master (how to show?

Describe the bug
No climate object for hassdiscovery discovered by z2m

To Reproduce
Steps to reproduce the behavior:

mqtt settings:
https://www.jottacloud.com/s/0067ee8821ea95340c89bee59db6a360528

device:
https://www.jottacloud.com/s/006d2c1b284d53d4011bb1ac250d4acd9cc

Expected behavior
A clear and concise description of what you expected to happen.

Additional context
mosquitto:

discovery prefix:

± mosquitto_sub  -t 'homeassistant/+/1etg_BAD-Termostat/#' -v -h 192.168.67.11  | ts
nov. 30 21:50:53 homeassistant/sensor/1etg_BAD-Termostat/electricity_kvah_meter/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"kWh","state_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-value-65537"}
nov. 30 21:50:53 homeassistant/sensor/1etg_BAD-Termostat/electricity_kvah_meter_deltaTime/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"s","state_topic":"z2m/1etg_BAD/Termostat/50/1/deltaTime/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/deltaTime/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_deltaTime","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-deltaTime-66561"}
nov. 30 21:50:53 homeassistant/sensor/1etg_BAD-Termostat/electricity_kvah_meter_value/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"V","state_topic":"z2m/1etg_BAD/Termostat/50/1/value/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/value/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_value","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-value-66561"}
nov. 30 21:50:53 homeassistant/sensor/1etg_BAD-Termostat/electricity_kvah_meter_previousValue/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"V","state_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_previousValue","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-previousValue-66561"}

mqtt prefix:

± mosquitto_sub  -t 'z2m/+/1etg_BAD-Termostat/#' -v -h 192.168.67.11  | ts
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_unknown_meter/config {"value_template":"{{ value_json.value }}","device_class":"power","state_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"Unknown manufacturer 411","model":"undefined (undefined)","name":"1etg_BAD-Termostat","sw_version":"0.0.0"},"name":"1etg_BAD-Termostat_electricity_unknown_meter","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-value-65537"}
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_unknown_meter_undefined/config {"value_template":"{{ value_json.value }}","device_class":"power","state_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"Unknown manufacturer 411","model":"undefined (undefined)","name":"1etg_BAD-Termostat","sw_version":"0.0.0"},"name":"1etg_BAD-Termostat_electricity_unknown_meter_undefined","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-previousValue-66561"}
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_kvah_meter/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"kWh","state_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/value/65537","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-value-65537"}
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_kvah_meter_deltaTime/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"s","state_topic":"z2m/1etg_BAD/Termostat/50/1/deltaTime/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/deltaTime/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_deltaTime","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-deltaTime-66561"}
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_kvah_meter_value/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"V","state_topic":"z2m/1etg_BAD/Termostat/50/1/value/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/value/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_value","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-value-66561"}
nov. 30 21:55:52 z2m/sensor/1etg_BAD-Termostat/electricity_kvah_meter_previousValue/config {"value_template":"{{ value_json.value }}","device_class":"power","unit_of_measurement":"V","state_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","json_attributes_topic":"z2m/1etg_BAD/Termostat/50/1/previousValue/66561","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node3"],"manufacturer":"ThermoFloor","model":"Floor thermostat (Heatit Z-TRM3)","name":"1etg_BAD-Termostat","sw_version":"4.0"},"name":"1etg_BAD-Termostat_electricity_kvah_meter_previousValue","unique_id":"zwavejs2mqtt_0xedda91c5_3-50-1-previousValue-66561"}

Related to #105

Version

Build/Run method

• [*] Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha.0 (dev tag)

Describe the bug
A removed node breaks the network mesh graph with the following error in the console.

vue.esm.js:1897 Error: missing: 7
    at D (vue-d3-network.umd.js:5313)
    at d (vue-d3-network.umd.js:5363)
    at Function.B.u.initialize (vue-d3-network.umd.js:5394)
    at f (vue-d3-network.umd.js:5727)
    at Object.force (vue-d3-network.umd.js:5769)
    at o.simulate (vue-d3-network.umd.js:7753)
    at o.animate (vue-d3-network.umd.js:7785)
    at o.reset (vue-d3-network.umd.js:7789)
    at o.netLinks (vue-d3-network.umd.js:7633)
    at pn.run (vue.esm.js:4577)
Yt @ vue.esm.js:1897

To Reproduce
Steps to reproduce the behavior:

1. Exclude a node from the mesh
2. Open the network graph option

Expected behavior
A working network mesh graph even when nodes are removed.

After a Refresh Info command, values are empty

trying to fix this as also

1. UI has empty values
2. Log shows no values in console

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: I'm not sure how to get this. I'm using zwavejs/zwavejs2mqtt:dev pulled on 12th Dec

Describe the bug
GreenWave Reality Inc. Multi-socket PowerNode (6 plugs) - Manufacturer ID=153, Product Type=3, Product ID=4 doesn't report Watt meter for sockets 2, 3, 4, 5 and 6.

OpenZWave stack and OpenHab ZWave bindings are able to get that information. For instance, from OpenZWave stack (using docker openzwave/ozwdaemon:latest) you can see that information:

I'm not sure if this is a zwavejs problem not recognizing all the device information or a HA discover issue. If further details are needed, please let me know.

Expected behavior
Watts meter for all the 6 plugs into device are expected

Since #25 is about to be merged.

It would be nice that we can create multicast groups using the gateway website.

The idea is to rename groups to association (since that is the current behavior of the groups tab).
After that then we could see a multicast request to a selection of nodes as a group.

The website should make sure that the correct nodes are matched with the correct command classes, and once a group is created using the website a new topic is created on which we can set values like if it is a normal device.

Groups can than also be detected via the Hass discovery in openhab / hass.

By doing this all zwave gouping logic is in the zwave2mqtr backend and not in the home automation tool.

The zigbee2mqtt also does this but not sure if the zwave protocol behaves the same.

So in short

• Ability to group nodes using the website
• Ability to send commands via a new topic to that (multicast) group just like normal devices.

Is it possible to send a version of currently installed zwave2mqtt to mqtt?

The Idea is to create one atomation / notification if there are a new version

Ideal would be a topic with the current version and the currently available master/dev. But the current one would be very helpful.

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: c762a85 (master)

Describe the bug
When I click on the settings icon, I am sent to /settings. This works. If I then click refresh page, it crashes. The same happens with /mesh.

To Reproduce
Steps to reproduce the behavior:

1. Click on the settings symbol.
2. Click refresh page on your browser
3. See crash error:

Error: Not Found
    at /usr/src/app/app.js:255:15
    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/usr/src/app/node_modules/express/lib/router/index.js:317:13)
    at /usr/src/app/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:335:12)
    at next (/usr/src/app/node_modules/express/lib/router/index.js:275:10)
    at /usr/src/app/node_modules/connect-history-api-fallback/lib/index.js:85:5
    at Layer.handle [as handle_request] (/usr/src/app/node_modules/express/lib/router/layer.js:95:5)
    at trim_prefix (/usr/src/app/node_modules/express/lib/router/index.js:317:13)
    at /usr/src/app/node_modules/express/lib/router/index.js:284:7
    at Function.process_params (/usr/src/app/node_modules/express/lib/router/index.js:335:12)
    at next (/usr/src/app/node_modules/express/lib/router/index.js:275:10)
    at cors (/usr/src/app/node_modules/cors/lib/index.js:188:7)
    at /usr/src/app/node_modules/cors/lib/index.js:224:17
    at originCallback (/usr/src/app/node_modules/cors/lib/index.js:214:15)
    at /usr/src/app/node_modules/cors/lib/index.js:219:13

Expected behavior
The same page should load correctly.

How to change the path where the store-data is stored?

Issue

We currently face an issue, which the previous driver solved with it's own internal process.

The new driver (zwave-js) does manage all the value updates from different command classes. There are specific classes which might enter a state, but have no signal of exiting this state. This is by design of Z-wave and unfortunately we cannot avoid it. The reason usually is for saving energy.

An example is the Central Scene, which delivers information about button press (short), button hold down and button release (and only release in case was hold down).
In this situation, once we press the button for a short time, we do not receive an update for it's release.

Pressing the button, and triggering short press, this happens:

1. Cache keeps the last state as button pressed
2. If already been pressed before, new state is from
   z2m:Zwave Node 87: value updated: 91-0-scene-004 0 => 0
3. There is no inactive state.

Previous driver was behaving like this:

2020-12-13T12:47:35.599Z z2m:Zwave zwave node 87: changed: 91-1-3:Scene 3:Inactive -> Pressed 1 Time
2020-12-13T12:47:36.599Z z2m:Zwave zwave node 87: changed: 91-1-3:Scene 3:Pressed 1 Time -> Inactive

The current way, causes issues on automations, as we can by a restart trigger a button press (from cache)

Proposal for more solving this

I suggest to add a category of command classes called State Sensitive Command Class. This will have some different characteristics compared to remaining classes

Proposed characteristics to support

• On startup or restart: do not update the value from cache, and set the proprty with undefined value
• Ability On Value update, after specific time (which can be configurable) to revert to undefined value (global SSCC setting)
• Ability to enable/disable the Retention of topics of SSCC
• Add value on payload for better understanding where the value comes from (from cache or not)

Version

Build/Run method

• [ x ] Docker
• PKG
• [ x ] Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 0.0.0

Describe the bug

Triggering switch for the sirene in hass:

 2020-12-02T07:19:55.795Z z2m:Mqtt Message received on z2m/nodeID_5/37/0/currentValue/set                                                                                                                          
 2020-12-02T07:19:55.797Z z2m:Zwave Driver: Binary Switch: "currentValue" is not a supported property                                                                                                              
 2020-12-02T07:19:55.798Z z2m:Zwave Unable to write true on 5-37-0-currentValue  

Startup:

2020-12-02T07:24:01.772Z z2m:Zwave Node 5: value updated: 128-0-level 18 => 18
2020-12-02T07:24:01.772Z z2m:Zwave Node 5: value updated: 128-0-isLow false => false
2020-12-02T07:24:01.776Z z2m:Zwave Node 5 is alive
2020-12-02T07:24:01.791Z z2m:Zwave Node 5: value added 5-37-0-currentValue => false
2020-12-02T07:24:01.791Z z2m:Zwave Node 5: value added 5-37-0-targetValue => undefined
2020-12-02T07:24:01.791Z z2m:Zwave Node 5: value added 5-94-0-zwavePlusVersion => 1
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-94-0-nodeType => 0
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-94-0-roleType => 7
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-94-0-installerIcon => 3840
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-94-0-userIcon => 3840
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-112-0-1 => 3
2020-12-02T07:24:01.792Z z2m:Zwave Node 5: value added 5-112-0-2 => 2
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-112-0-3 => 1
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-112-0-4 => 1
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-112-0-5 => 10
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-112-0-6 => 9
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-112-0-7 => 1
2020-12-02T07:24:01.793Z z2m:Zwave Node 5: value added 5-113-0-Siren-Siren status => 0
2020-12-02T07:24:01.794Z z2m:Zwave Node 5: value added 5-114-0-manufacturerId => 600
2020-12-02T07:24:01.794Z z2m:Zwave Node 5: value added 5-114-0-productType => 3
2020-12-02T07:24:01.794Z z2m:Zwave Node 5: value added 5-114-0-productId => 4232
2020-12-02T07:24:01.794Z z2m:Zwave Node 5: value added 5-128-0-level => 18
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-128-0-isLow => false
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-134-0-libraryType => 6
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-134-0-protocolVersion => 4.38
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-134-0-firmwareVersions => 2.94
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-134-0-hardwareVersion => undefined
2020-12-02T07:24:01.795Z z2m:Zwave Node 5: value added 5-135-0-value => 0
2020-12-02T07:24:01.796Z z2m:Zwave Node 5 ready: Shenzhen Neo Electronics Co., Ltd. - NAS-AB01Z (Siren Alarm)

hass discovery:

des. 02 08:26:18 homeassistant/switch/nodeID_5/switch/config {"payload_off":false,"payload_on":true,"value_template":"{{ value_json.value }}","command_topic":"z2m/nodeID_5/37/0/currentValue/set","state_topic":"z2m/nodeID_5/37/0/currentValue","device":{"identifiers":["zwavejs2mqtt_0xedda91c5_node5"],"manufacturer":"Shenzhen Neo Electronics Co., Ltd.","model":"Siren Alarm (NAS-AB01Z)","name":"nodeID_5","sw_version":"2.94"},"name":"nodeID_5_switch","unique_id":"zwavejs2mqtt_0xedda91c5_5-37-0-currentValue"}

Expected behavior
Trigger sirene as in the webgui which works.

Hi,

I am migrating from openhab zwave implementation via zwave2mqtt to zwavejs2mqtt (I was pointed to here via an other issue).

My environment:
I am running zwavejs2mqtt ("patched" dev image see #15) in a docker (podman) container on my linux pc.
For testing purposes i've removed one of my Firabro Roller Shutter 3 units (FGR223) from the wall and put it next to me.

I have a Aeotec Z‐Stick Gen5 USB Controller, and paired to only one FGR223 for the moment.

My problem:
No 38/1/currentValue update when movement stops when:

• I send a level request to the "zwavejs2mqtt/2/38/1/targetValue/set" topic i only get one position update back in the "zwavejs2mqtt/2/38/1/currentValue" topic when movement starts.
• I send a UP or DOWN or STOP (false) to the corresponding topics, i also don't see a current value beeing reported (also no update when movement starts).

See logs:

• Level change from position 99 -> 80 -> 60 -> 40, the next level request is send some seconds after i hear the relay click to stop.
  99-80-60-40.log

• Sending "UP" and STOP to the UP topic.
  log-up-stop.log

My analysis:
My feeling is that this might be a OpenZwave issue since it seems like the same behavior i have in openhab (not sure if that is actually OpenZwave, but looks pretty similar with the zwave-xml files), but never the less.
Or maby the device just not reports when it is done, but do see a electricity report update after a second or two after the relay clicks.

Question:
I was also wondering if there is an work-around available by the means of a "/get" on the topic so that the controller will re-request the value from the device.
Why, because if i restart the zwavejs2mqtt container, i do get the correct value in the currentValue topic.

Thnx!

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: 1.0.0-alpha.1

Describe the bug
Some entities are missing in Home Assistant. The problem is that zwavejs2mqtt is creating topics in MQTT with spaces in topic name. As an example, one of sensor configurations is under topic
homeassistant/sensor/n015_ws_boilerw/notification_Water Alarm/config (space between Water and Alarm).
If I replace the space with underscore in the topic name: homeassistant/sensor/n015_ws_boilerw/notification_Water_Alarm/config, the entity shows up in home assistant. It would be also nice to have topic name all lower case.
Thank you!

Related to #105

Hi,

Im am slowly integrating into openhab, i want to use the openhab model "RollerShutter" to control my shutters.

It has 3 buttons -> up (value 99) -> stop ( value stop / or custom) -> down (value 0), i can also send a level in the form of a number between 0 - 100 (which is than mapped the openhab mqtt config to 0-99).

What is does is sending a request to the zwavejs2mqtt/study/switch_multilevel/endpoint_1/targetValue/set

In there model i cannot select a other topic to send the stop command to.
It would be nice that i can send the "stop" word or any other value op the targetValue/set topic to use the build in openhab model, i think home assistant is using the same approach.

Currenly i am using the "dimmer" model to send values and use a openhab switch to send stop (by means of sending false) the Up or Down topic.

Thnx!

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: master

Describe the bug
The switch is identified as a dimmer, and I cannot turn it on of of.
I can set Target value and Transition duration in the zwavejs2mqtt web UI, which doesn't work. The same happens in Home Assistant.

To Reproduce
Steps to reproduce the behavior:

1. Include such switch into network
2. Go to user values
3. Observe dimmer properties

Expected behavior
Expected result is to have an on/off switch and not a dimmer value.

Additional context
The same happens with my Aeotec Smart Swich 6 wall switch. However, my Neo CoolCam NAS-WR01ZE wall switch works as expected.

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: master

Describe the bug
Missing the 113-0-Home_Security-* command classes in the dashboard for motion and door sensors.

Expected behavior
I expect to see 113-0-Home_Security-Motion_sensor_status and 113-0-Home_Security-Cover_status in the dashboard under the User section

Additional context

Version

Build/Run method

• Docker
• PKG
• Manually built (git clone - npm install - npm run build )

zwavejs2mqtt version: I'm not sure how to get this. I'm using zwavejs/zwavejs2mqtt:dev pulled on 24th Dec

Describe the bug
Missing HASS devices for NodOn Octan Remote Controller CRC-3100.
Manufacturer ID: 357
Product Type: 2
Product ID: 1

Once you hace included your Noctan Octan remote controller into the ZWave network, with this configuration (Central Scene):

Each botton is identified like this into ZWaveJS2MQTT GUI:

Meaning, each one is identified by [node]-91-0-scene-00X with X=1, 2, 3, 4

However, not all of them are "converted" to devices for HASS.

"sensor_scene_state" is for topic "91/0/slowRefresh"

And the relevant one "sensor_scene_state_0" is created for topic "91/0/scene/002":

There are no devices for scenes 001, 003 or 004 hence HASS isn't aware when you click (or double click or hold,...) the other three buttons.

I've defined these devices manually and it did the trick.
Note: The "sensor_scene_state_02" is basically the same than the automatically discovered "sensor_scene_state_0" but just assigning a name with the same pattern than the 01/03/04 to make it a little bit more consistent:

{
  "type": "sensor",
  "object_id": "scene_state_01",
  "discovery_payload": {
    "state_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/001",
    "value_template": "{{ value_json.value}}",
    "json_attributes_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/001",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xf77d3d75_node9"
      ],
      "manufacturer": "ID-RF",
      "model": "Octan Remote Control (CRC-3100)",
      "name": "LR-RemoteNodOn",
      "sw_version": "2.3"
    },
    "name": "LR-RemoteNodOn_scene_state_01",
    "unique_id": "zwavejs2mqtt_0xf77d3d75_9-91-0-scene-001"
  },
  "discoveryTopic": "sensor/LR-RemoteNodOn/scene_state_001/config",
  "values": [
    "91-0-scene-001"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state_01"
}

{
  "type": "sensor",
  "object_id": "scene_state_02",
  "discovery_payload": {
    "state_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/002",
    "value_template": "{{ value_json.value}}",
    "json_attributes_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/002",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xf77d3d75_node9"
      ],
      "manufacturer": "ID-RF",
      "model": "Octan Remote Control (CRC-3100)",
      "name": "LR-RemoteNodOn",
      "sw_version": "2.3"
    },
    "name": "LR-RemoteNodOn_scene_state_02",
    "unique_id": "zwavejs2mqtt_0xf77d3d75_9-91-0-scene-002"
  },
  "discoveryTopic": "sensor/LR-RemoteNodOn/scene_state_002/config",
  "values": [
    "91-0-scene-002"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state_02"
}

{
  "type": "sensor",
  "object_id": "scene_state_03",
  "discovery_payload": {
    "state_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/003",
    "value_template": "{{ value_json.value}}",
    "json_attributes_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/003",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xf77d3d75_node9"
      ],
      "manufacturer": "ID-RF",
      "model": "Octan Remote Control (CRC-3100)",
      "name": "LR-RemoteNodOn",
      "sw_version": "2.3"
    },
    "name": "LR-RemoteNodOn_scene_state_03",
    "unique_id": "zwavejs2mqtt_0xf77d3d75_9-91-0-scene-003"
  },
  "discoveryTopic": "sensor/LR-RemoteNodOn/scene_state_003/config",
  "values": [
    "91-0-scene-003"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state_03"
}

{
  "type": "sensor",
  "object_id": "scene_state_04",
  "discovery_payload": {
    "state_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/004",
    "value_template": "{{ value_json.value}}",
    "json_attributes_topic": "zwavejs/LR/RemoteNodOn/91/0/scene/004",
    "device": {
      "identifiers": [
        "zwavejs2mqtt_0xf77d3d75_node9"
      ],
      "manufacturer": "ID-RF",
      "model": "Octan Remote Control (CRC-3100)",
      "name": "LR-RemoteNodOn",
      "sw_version": "2.3"
    },
    "name": "LR-RemoteNodOn_scene_state_04",
    "unique_id": "zwavejs2mqtt_0xf77d3d75_9-91-0-scene-004"
  },
  "discoveryTopic": "sensor/LR-RemoteNodOn/scene_state_004/config",
  "values": [
    "91-0-scene-004"
  ],
  "persistent": false,
  "ignoreDiscovery": false,
  "id": "sensor_scene_state_04"
}

Is it possible for ZWaveJS2MQTT to autodiscover the four scenes and not just one of them? Or am I missing something?

Thank you in advance

zwave-js/node-zwave-js#806

Version

Build/Run method

• Docker (Digest sha256:3b37d20d1f5b2e508ee8a261101b22d825ced779a6ca772719452a6c9f0e21ae)

zwavejs2mqtt version: 1.0.0-alpha.1

Describe the bug
I start the fresh loaded docker image zwavejs/zwavejs2mqtt with folder mount, where no files currently exist.

I see following output.

 ______                       _     ___                  _   _
|___  /                      (_)   |__ \                | | | |
   / /_      ____ ___   _____ _ ___   ) |_ __ ___   __ _| |_| |_
  / /\ \ /\ / / _` \ \ / / _ \ / __| / /| '_ ` _ \ / _` | __| __|
 / /__\ V  V / (_| |\ V /  __/ \__ \/ /_| | | | | | (_| | |_| |_
/_____|\_/\_/ \__,_| \_/ \___| |___/____|_| |_| |_|\__, |\__|\__|
                            _/ |                      | |
                           |__/                       |_|

2020-12-20 13:30:33.412 WARN STORE: settings.json not found
2020-12-20 13:30:33.620 WARN STORE: scenes.json not found
2020-12-20 13:30:33.625 WARN STORE: nodes.json not found
/bin/sh: git: not found
2020-12-20 13:30:38.942 INFO APP: Version: 1.0.0-alpha.1
2020-12-20 13:30:38.945 INFO APP: Application path:/usr/src/app
TypeError: Cannot read property 'logEnabled' of undefined
    at setupLogging (/usr/src/app/app.js:43:31)
    at startGateway (/usr/src/app/app.js:56:3)
    at start (/usr/src/app/app.js:38:3)
    at /usr/src/app/bin/www:98:5
    at tryCatcher (/usr/src/app/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/usr/src/app/node_modules/bluebird/js/release/promise.js:547:31)
    at Promise._settlePromise (/usr/src/app/node_modules/bluebird/js/release/promise.js:604:18)
    at Promise._settlePromise0 (/usr/src/app/node_modules/bluebird/js/release/promise.js:649:10)
    at Promise._settlePromises (/usr/src/app/node_modules/bluebird/js/release/promise.js:729:18)
    at _drainQueueStep (/usr/src/app/node_modules/bluebird/js/release/async.js:93:12)
    at _drainQueue (/usr/src/app/node_modules/bluebird/js/release/async.js:86:9)
    at Async._drainQueues (/usr/src/app/node_modules/bluebird/js/release/async.js:102:5)
    at Immediate.Async.drainQueues [as _onImmediate] (/usr/src/app/node_modules/bluebird/js/release/async.js:15:14)
    at processImmediate (internal/timers.js:461:21)

Expected behavior

• Zwave2mqtt starts without any errors and does not crash at the end.
• I don't expect dependency to git inside of docker container

Additional context
I try to run on raspberry pi which was able to run ozw variant of zwave2mqtt