Are you saying you have to disable onboard bluetooth to get a connection via your zwave controller? If not can you clarify please.
I did the switch to Zwave JS last week and it was not without some issues, some devices did not want to talk correctly (mainly secure devices) but I was running old firmware as some devices did not talk nicely with OZW when I upgraded (probably old device files) so I upgraded all my devices and added them and now everything is running just great!
I love the new setup with Zwave running as a separate server, restarts of HA is quick and painless now!
The integration (Z-Wave JS) seems to not be talking to the add-on correctly,
I should be running Zwave-js version 6.2.0 since I run version 0.1.6 of the Z-Wave JS add-on but when I open âConfigureâ of the integration it says:
Driver Version: 6.1.3
Server Version: 1.0.0-beta.5
Do I need to do something with the Integration to get it to update or is something wrong with my configuration?
Yes exactly, the Pi3 blutooth port apparently block the Razberry ZWave Controller. Just added the line.
refresh your browser, CTRL+F5
Well thatâs defo me not migrating. I need BT to work. I could get another controller (usb) but surely should not need to do this to fix a software bug . Iâll wait.
I read somewhere you may get basic BT, whatever that means, on the Pi3 with the Razberry Zwave Controller installed. It could be my specific setup not letting the Zwave JS connect without disabling the BT. đ¤ˇ
I would be grateful for any advice about getting the Fibaro FGMS-001 motion sensor to show when motion occurs.
I have Z-wave JS up and running with ZwaveJS2MQTT and running HA core in Docker on a Pi 4. All my z-wave devices have been registered in HA including the Fibaro motion sensors. But I cannot see the binary_sensor entity for detecting motion.
Here is the debug info in ZwaveJSMQTT for one of the motion sensors. The only boolean I can see is the low battery level. Rather oddly I have another motion sensor that doesnât even show all the entities the one below shows (it is missing the seismic entity and the three acceleration axes). I have tried re-interviewing these nodes and refreshing them (what is the difference between these two?) but no change. Will I have to unpair them and repair them to fix this?
Thank you for your advice.
{
"id": 18,
"deviceId": "271-4097-2049",
"manufacturer": "Fibargroup",
"manufacturerId": 271,
"productType": 2049,
"productId": 4097,
"name": "",
"loc": "",
"values": [
{
"id": "18-134-0-libraryType",
"nodeId": 18,
"commandClass": 134,
"commandClassName": "Version",
"endpoint": 0,
"property": "libraryType",
"propertyName": "libraryType",
"type": "any",
"readable": true,
"writeable": false,
"label": "Library type",
"stateless": false,
"list": false,
"lastUpdate": 1613335884253
},
{
"id": "18-134-0-protocolVersion",
"nodeId": 18,
"commandClass": 134,
"commandClassName": "Version",
"endpoint": 0,
"property": "protocolVersion",
"propertyName": "protocolVersion",
"type": "any",
"readable": true,
"writeable": false,
"label": "Z-Wave protocol version",
"stateless": false,
"list": false,
"lastUpdate": 1613335884254
},
{
"id": "18-134-0-firmwareVersions",
"nodeId": 18,
"commandClass": 134,
"commandClassName": "Version",
"endpoint": 0,
"property": "firmwareVersions",
"propertyName": "firmwareVersions",
"type": "any",
"readable": true,
"writeable": false,
"label": "Z-Wave chip firmware versions",
"stateless": false,
"list": false,
"lastUpdate": 1613335884256
},
{
"id": "18-114-0-manufacturerId",
"nodeId": 18,
"commandClass": 114,
"commandClassName": "Manufacturer Specific",
"endpoint": 0,
"property": "manufacturerId",
"propertyName": "manufacturerId",
"type": "number",
"readable": true,
"writeable": false,
"label": "Manufacturer ID",
"stateless": false,
"min": 0,
"max": 65535,
"list": false,
"value": 271,
"newValue": 271
},
{
"id": "18-114-0-productType",
"nodeId": 18,
"commandClass": 114,
"commandClassName": "Manufacturer Specific",
"endpoint": 0,
"property": "productType",
"propertyName": "productType",
"type": "number",
"readable": true,
"writeable": false,
"label": "Product type",
"stateless": false,
"min": 0,
"max": 65535,
"list": false,
"value": 2049,
"newValue": 2049
},
{
"id": "18-114-0-productId",
"nodeId": 18,
"commandClass": 114,
"commandClassName": "Manufacturer Specific",
"endpoint": 0,
"property": "productId",
"propertyName": "productId",
"type": "number",
"readable": true,
"writeable": false,
"label": "Product ID",
"stateless": false,
"min": 0,
"max": 65535,
"list": false,
"value": 4097,
"newValue": 4097
},
{
"id": "18-128-0-level",
"nodeId": 18,
"commandClass": 128,
"commandClassName": "Battery",
"endpoint": 0,
"property": "level",
"propertyName": "level",
"type": "number",
"readable": true,
"writeable": false,
"label": "Battery level",
"stateless": false,
"min": 0,
"max": 100,
"unit": "%",
"list": false,
"value": 55,
"lastUpdate": 1613335884277,
"newValue": 55
},
{
"id": "18-128-0-isLow",
"nodeId": 18,
"commandClass": 128,
"commandClassName": "Battery",
"endpoint": 0,
"property": "isLow",
"propertyName": "isLow",
"type": "boolean",
"readable": true,
"writeable": false,
"label": "Low battery level",
"stateless": false,
"list": false,
"value": false,
"newValue": false
},
{
"id": "18-49-0-Illuminance",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Illuminance",
"propertyName": "Illuminance",
"type": "number",
"readable": true,
"writeable": false,
"label": "Illuminance",
"stateless": false,
"ccSpecific": {
"sensorType": 3,
"scale": 1
},
"unit": "Lux",
"list": false,
"value": 78,
"newValue": 78
},
{
"id": "18-49-0-Air temperature",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Air temperature",
"propertyName": "Air temperature",
"type": "number",
"readable": true,
"writeable": false,
"label": "Air temperature",
"stateless": false,
"ccSpecific": {
"sensorType": 1,
"scale": 0
},
"unit": "°C",
"list": false,
"value": 20.6,
"newValue": 20.6
},
{
"id": "18-49-0-Seismic Intensity",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Seismic Intensity",
"propertyName": "Seismic Intensity",
"type": "number",
"readable": true,
"writeable": false,
"label": "Seismic Intensity",
"stateless": false,
"ccSpecific": {
"sensorType": 25,
"scale": 0
},
"list": false,
"value": 0,
"newValue": 0
},
{
"id": "18-49-0-Acceleration X-axis",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Acceleration X-axis",
"propertyName": "Acceleration X-axis",
"type": "number",
"readable": true,
"writeable": false,
"label": "Acceleration X-axis",
"stateless": false,
"ccSpecific": {
"sensorType": 52,
"scale": 0
},
"unit": "m/s2",
"list": false,
"value": 0,
"newValue": 0
},
{
"id": "18-49-0-Acceleration Y-axis",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Acceleration Y-axis",
"propertyName": "Acceleration Y-axis",
"type": "number",
"readable": true,
"writeable": false,
"label": "Acceleration Y-axis",
"stateless": false,
"ccSpecific": {
"sensorType": 53,
"scale": 0
},
"unit": "m/s2",
"list": false,
"value": 0,
"newValue": 0
},
{
"id": "18-49-0-Acceleration Z-axis",
"nodeId": 18,
"commandClass": 49,
"commandClassName": "Multilevel Sensor",
"endpoint": 0,
"property": "Acceleration Z-axis",
"propertyName": "Acceleration Z-axis",
"type": "number",
"readable": true,
"writeable": false,
"label": "Acceleration Z-axis",
"stateless": false,
"ccSpecific": {
"sensorType": 54,
"scale": 0
},
"unit": "m/s2",
"list": false,
"value": 0,
"newValue": 0
}
],
"groups": [],
"neighbors": [
1,
5,
9,
10,
11,
12,
21,
25,
26
],
"ready": true,
"available": false,
"hassDevices": {},
"failed": false,
"lastActive": 1613335884285,
"interviewCompleted": true,
"isBeaming": true,
"isSecure": true,
"keepAwake": false,
"maxBaudRate": null,
"isRouting": true,
"isFrequentListening": false,
"isListening": false,
"status": "Awake",
"interviewStage": "Complete",
"productLabel": "FGMS001",
"productDescription": "Motion Sensor",
"zwaveVersion": 4,
"deviceClass": {
"basic": 4,
"generic": 7,
"specific": 1
},
"hexId": "0x010f-0x1001-0x0801",
"_name": "NodeID_18"
}
Possibly means âstandardâ energy bluetooth, i.e. not LEBT (Low Energy Bluetooth) a protocol that devices use to such as battery operated small sensors (room temperature, motion sensor, and so on). LoL, itâs the only devices I have.
From my experience, I was under the impression that the â48-0-anyâ topic is the collector for motion sensor as âtrue/falseâ value. I see you have , for node 18 , the Topic related:-
- 134-0 Protocol
- 114-0 Manufacturer
- 128-0 Battery
- 49-0 Multi-Level Sensors
but
- 48-0 Binary Sensor is missing
I would check the host OS, host drivers and software stack, the ZW full log, ZW driver database entries, HA logs, debug of the components, Association groups and logs, controller info, etc.etc. which you are using. There are so many combinations of this - hundreds, thousands, and you do not give any of this information and thus I would imagine youâre not going to receive much either I guess because how can anyone know what your setup is in order to help.
By the way, I would start by ensuring what the ZWave stack driver database says about your sensor, and how they should be associated to the controller (i.e. Groups such as Sensor and Sensor BC). This would give you a sense of what is possible with your ZWave setup and how to go about it - after which you can start to debug. This may not be a HA issue so Google is your friend 
Thank you for your advice, it is a lot more complex than I realised. I had assumed that as the motion sensor was working satisfactorily 30 mins earlier with Openzwave beta (OZWD) there would be a seamless transfer. Is it logical to assume in this case that the problem lies in ZWJS? And rather than have to learn about the extensive list of components you mentioned could I simply unpair and then re-pair free motion sensors?
Ahha - therein lies the folly. The keyphrase I assert through my 35 yrs in software development, is
ânever assume anything in software!â. Software has (or should) a predictable logic, that is to say that the golden test is to ensure that every possible state within the machine programme must be logically defined and evaluated for all possible conditions within the domain being programmatically emulated or simulated. To assume something would be to fail such a test and render the state interminable - which is never a good state to be in !!
Not so much logical that the problem lies in ZWJS itself, but moreover there is - ostensibly - an issue somewhere in the complete stack that ZWJS uses, for your use-case. That is to say the actual problem may not be in ZWJS but âsomething it usesâ. Aside, that is precisely why I posted the OP. I sought to canvass experiences. Some will be good - no issues - some will be less good , such as yours. There is never a copper bottom guarantee with software.
That is what I would do because currently I do not have capacity in my daytime to investigate. If circumstances were different , I would, but now is not the right time for me. Again another reason for the OP. Everything is working perfectly at the moment so I am very hesitant to âfix that which is not brokenâ by âupgradingâ to ZWJS. Now may not be the best time and there is nothing forcing me to do so anyway - YET.
I do run daily backups so in practice I could just âtry itâ with ZWJS and then if it doesnât work then return to the backup. But even restoring backups can have a negative effect and cause rework. For example restoring a live database such as that which HA uses will mean I lose history on entities. This is just one example, there are many others I could cite in my use-case. Yes I could be selective in restore but thatâs more effort on top of effort on top of an action which I didnât really need to do. As I say, now is the wrong time for all this - for me - so I plan to stick with OZW.
I have one major pain in the ass with one node. Its a philio psp05. I can set all configs as desired, communication seems fine. However, the motion detector never goes away. After inclusion , it works one time and then never.
The âreport offâ is enabled, so it should report âmotion cooled downâ or somehting, but it does not work (while it did in deprecated zwave integration).
below, you see message coming in⌠and after 20 seconds orso, the reset should happen, but that message seems wrongly parsed. I cant remember literaly the config i had in openzwave 1.4, but it did just report properly no motion any more after the right amount of 24 seconds (3 times 8 seconds as config describes)
2021-02-16 11:54:08.580 INFO ZWAVE: Node 31: value updated: 128-0-level 100 => 100
2021-02-16 11:54:08.582 INFO ZWAVE: Node 31: value updated: 128-0-isLow false => false
2021-02-16 11:54:08.648 INFO ZWAVE: Node 31: value updated: 113-0-Home Security-Motion sensor status 8 => 8
2021-02-16 11:54:25.352 INFO ZWAVE: Node 31: value updated: 113-0-Home Security-unknown 254 => 254
Also tried binary setup, no avail.
feels kinda of a bug to me on this specific device, as other brand motion sensor (hank) is working fine
This thread relates to my OP query. This thread is not for new questions and issues, but rather experiences of moving to ZWJS. May I ask that it is not cluttered with questions unrelated - please. You should probably move your post to a new post in the configuration section and tag is with ZWave.
well, yes and no. I know how zwave configs work, and this is specifically an experience report in the context of ZWJS matter. I can remove the question if you want, or more report on nodes that do work?
btw depending on the JS server add in use, I see different behaviors in general. Anyone else tried the âjsâ vs âmqtt JSâ differrences?
If you would be so kind, that would be appreciated. Otherwise we can easily get to a scenario of multiple questions posted from different members, attracting multiple resolutions or suggestions, and cycling around these with replies and counter replies. This is going to hinder me as I try to pick out the âexperienceâ reports that I asked for in the OP. Iâm sure you understand - thank you.
I tried out switching from OZW to ZWJS and then ZJS2MQTT over the weekend. Things were mostly straight forward initially, but I was never able to get any of my battery powered door sensors, motion sensors, or smoke alarm to show up despite multiple attempts to wake up the devices and waiting ~24hrs. My battery powered Yale lock worked fine however. Everything without a battery showed up without issue. Response times were maybe a bit better with Z-Wave JS, but OZW performs fine for me so it was hard to say for sure. I took some videos and Iâll maybe do a frame-by-frame comparison later.
After wrestling with Docker for a bit, I was able to gracefully switch between the core Z-Wave JS and Z-Wave JS to MQTT add-ons without refreshing all devices by copying the cache files using HassOS root SSH access as documented in this post. In short, you can copy three Z-Wave JS cache files between the two versions of Z-Wave JS and switch between them without too much hassle (but donât docker cp or docker exec or you might have problems).
For now Iâd recommend using the Z-Wave JS to MQTT add-on if youâre just trying out Z-Wave JS. The core Z-Wave JS add-on doesnât have much in the way of visualization, logging or configuration options, and itâs really helpful to be able to change the Z-Wave JS log level, or look at the node list in the Z-Wave JS control panel to be able to understand what is happening under the hood for debugging.
Ultimately, I switched back to OZW. Everything just works for me in OZW. Iâll keep the Z-Wave JS add-ons installed but not started so I can easily try them out as updates are released.
Update: Not 100% sure it was related to trying out Z-Wave JS but my Yale lock stopped working after moving back to OZW. I pulled out the batteries on it and refreshed the node in the OZW admin and restarted the OZW add-on a few times and it came back 
1 Like
Thatâs a great bunch of info @johnboiles , much appreciated, and like you I find OZW âjust worksâ.ZWJS is a bit of a 50/50 for me I think at this time.
1 Like
while switching between those js servers, did you notice different entities being applied to HA ?
I only actually made the switch once, but Iâm pretty sure it kept the same integration entities when switching between the two add-ons.
I seem to have battery sensors that stop working. Seems when JS server reloads stuff (after settings change or whatever), the battery ones that do not regularly come awake, stop updating and no longer have working entities in HA.
Kind of kick back on this migration. iâm sure devs can make it more stable, but for now it would keep beta sticker for me.