Having some trouble getting the Fibaro TRV device working with the ZWay bridge. The device works in the ZWay (Zwave.Me) Smart Home GUI, and creates a number of devices in OpenLuup, some of which appear to have the right variables in it. Changing the XML and JSON files makes no difference.
I also tried creating a separate child device for Parameter 67 (using the gui for the ZWay bridge, see below), and setting the XML/JSON types for that device (like I've havd to do for a few other devices). This results in a device that correctly displays the TRV setpoint, but chaning the setpoint in the OpenLuup gui does not result in anything being transmitted to/by ZWay.
20490 49-0 D_ComboDevice1.xml zNode #49-0
20491 49-1 D_ComboDevice1.xml zNode #49-1
25031 49-1-67-1 D_Heater1.xml Radiator Bedroom
20492 49-2 D_ComboDevice1.xml multi #49-2
25030 49-2-49-1 D_TemperatureSensor1.xml Radiator Bedroom
Nearly there with the migration ..
Is it ok to use older device files or do they get updated from time to time?
Now that a fresh openLuup is up and running and connected to Zway where's the best place to source device files without vera? I probably have them on another openLuup install but not 100% which ones to copy over.
I've finally gotten the stuff to work together. Now - before I migrate all the vera devices, how do i use this?
How does the variables NameDevices and CloneRooms work? (is there a manual or description of the plugin?)Set up rooms and names in Z-way? No rooms in z-way, and distribute them in openluup?
CloneRooms seems obvious, but is that the best way to go when I have more bridges?
I have an old Z-wave.me wall controller that I still use for turning the espresso machine on and off. The controller controls an Aeotec Micro Switch that for the moment is still on my Vera.
The wall controller has always been a bit tricky to work with on Vera. On my old UI5 VeraLite I managed to get it associated to the switch.
On the UI7 Vera I never got that to work, instead I could use it as a trigger in Reactor to detect when sl_SceneActivated was 1 or 0.
I have moved the wall controller to Z-way and there it is included as it should.
a30b06dd-1f3c-4ca6-9966-b0a6f183de04-image.png Compared to when it was connected to the Vera it has proper on/off buttons so that it can be controlled from the Z-way GUI.
The command classes are the following:
68a54e6b-b240-40b2-95bb-9696bf7789cf-image.png In OpenLuup it still shows up as it did in the Vera, i.e. only showing battery.
985acfb7-6af9-4cf0-a426-79d4358baf6e-image.png Is it possible to change device type so that it get the right properties in OpenLuup?
At the moment it does not have any useful properties except for battery level. It e.g. lacks the sl_SceneActivated variable.
Another step would then be to move the Aeotec switch to Z-way and to then associate the wall controller to the switch in Z-way. It seems as if this can be done in the ExpertUI.
I hope this is the correct forum – apologies if not!
I have a Raspberry Pi3 with a Razberry Z-Wave card installed. I have installed the Z-Way software and have successfully included a Fibaro Z-Wave switch on the Z-Wave network. I can toggle the switch on and off successfully from my laptop through port 8083 of the Raspberry Pi3.
On the same Raspberry Pi3 I have installed openLuup on which I have installed the Z-Way plugin. I can access this through port 3480 on the Raspberry Pi3 from my laptop.
Here is where I have come to a dead stop. How do I get access to the Fibaro Z-Wave switch from the openLuup application? I can find no documentation that tells me specifically how to do this.
Any help would be greatly appreciated.
Just finished migrating to Zway, Although there are some devices that are being detected as a dimmer when in fact are Shutters.
What would be the best route to properly change how this devices are being detected by the ZWay plugin on openluup?
I must be missing something but I am having now some devices fail on the bridge due to them running out of battery. Upon battery replacement, they function properly on z-way-server but the failure remains over the bridge. The failure shows up on the parent device and it says that a specific command class has failed. Looking at the return API json, it should not return any command class level failure however so I am not sure where the bridge gets its failed state from...
edit: Nevermind, I figured it out. It is a gap in data alignment between the different z-way APIs. The zwave and JS API got the update that the device recovered but not the smarthome API. Pausing and restarting the zwave app on z-way fixed it.
I noticed the change when I switched from the RaZberry to UZB (During the switch all devices moved to the Room 101 briefly, maybe that had something to do with it). Any idea why this would have happened? Can I easily change them all back to enabled? Also, what exactly does this attribute do? I only noticed because none of my z-wave devices were showing up in Imperihome and when I set the "disabled" attribute back to 0, the device shows up. Thanks.
So I started experimenting by moving some of my wallplugs and power switch zwave devices over from VeraPlus to Z-Way.
In Z-Way this results in different elements for switching, Watts and kWh. Some even have Volts which I never saw on Vera.
But using the Z-Way plugin in openLuup only the Switch element is visible and all other elements of the zwave node are not.
I don't really know to much about Z-Way or the plugin, but am trying to learn on the run.
Maybe someone can give me some pointers what and where to look for to solve this?
Just wanted to point out and start the topic of the following:
We are working on a project that will allow to use Z-Way library as the core of Z-Wave in Home Assistant. First releases will be around June/July I believe
Additionally there are ways to support Z-Way from HAss via HTTP requests. This is a community project and we have no deep knowledge about it.
С уважением,Apr 19, 2020 Official Z-way integration request Official Z-way integration request
Why would that make you reluctant? It doesn’t seem to be any different from any other local startup supporting funds in other countries.
Recreate Zway device in Openluup
If a zway device have been manually deleted in openluup, What would be the right way to recreate it, or re-sync with the z-way-server?
Currently it does not resync with a luup restart.
I'm surprised. What's in the logs?
Oh, no wait. I misunderstood, perhaps. You mean that you have deleted the Zway plugin?
When I finished creating the new z-way-server setup. I went back to openluup and deleted an old ZWay device (not the ZWay plugin itself) that was there from the old z-way-server setup and re-login the ZWay plugin into the z-way-server, everything got transfer over except that one device.
This happened in another openluup setup. If I manually delete a ZWay device from openluup and then reload the luup engine or getting the ZWay plugin to login to a new z-way-server, z-way-server devices that matches the device id of the device that was deleted in openluup won't get created.
The device isn’t just in Room 101?
no. not in there either.
Which version of openLuup and the ZWay plugin?
Why are you deleting devices?
I had an old device from an old z-way-server and I didn't want to start a brand new user_data. I even try to connect the openluup zway plugin with the new z-way-server without deleting the device but the old device remained as the old device type and did not update to what the new z-way-server had under that id. so then I tried deleting it to never see it again... It has happen on two different setup I'm currently migrating.
I am unable to reproduce this.
I have deleted a ZWay child device, and restarted. During the ZWay plugin initialization, it notices the missing device, recreates it (with the same numbering) and requests another reload, after which the device is there again, as it should be.
How are you viewing your devices? AltUI? Have you done a browser refresh??
Here's the log of the ZWay plugin starting up and making a new device (#20050)
2020-10-03 11:13:33.324 openLuup.scheduler::  ZWay device startup
2020-10-03 11:13:33.324 luup_log:23: ZWay: v20.7.14
2020-10-03 11:13:33.382 luup_log:23: ZWay: HomeId: c5d860ea
2020-10-03 11:13:33.382 luup.variable_set:: 23.urn:upnp-org:serviceId:altui1.DisplayLine1 was: 52 vDevs, 24 zNodes now: #hooks:0
2020-10-03 11:13:33.382 luup.register_handler:: global_function_name=HTTP_Z-Way_23, request=z23
2020-10-03 11:13:33.421 luup.set_failure:: status = 0
2020-10-03 11:13:33.421 luup.variable_set:: 23.urn:micasaverde-com:serviceId:HaDevice1.CommFailure was: 0 now: 0 #hooks:0
2020-10-03 11:13:33.421 luup.variable_set:: 23.urn:micasaverde-com:serviceId:HaDevice1.CommFailureTime was: 0 now: 0 #hooks:0
2020-10-03 11:13:33.481 luup.variable_get:: No such device/serviceId/name 20050.urn:akbooer-com:serviceId:ZWay1.Children
2020-10-03 11:13:33.482 luup.create_device::  D_MotionSensor1.xml / / D_MotionSensor1.json (urn:schemas-micasaverde-com:device:MotionSensor:1)
2020-10-03 11:13:33.482 luup.variable_set:: 20200.urn:upnp-org:serviceId:altui1.DisplayLine1 was: Humidity:1 Light:1 Motion:1 Temperature:1 now: Humidity:1 Light:1 Motion:1 Temperature:1 #hooks:0
2020-10-03 11:13:33.482 luup_log:23: creating device numbers: [20170,20084,20080,20213,20040,20180,20140,20182,20100,20020,20050,20200,25001,25002,25003,25004,20085,20215,20214,20083,20212,20211,20210,20081,20190,20110,20181,20082]
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Everspring Dimmer (2.0)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  TKB Home Switch (#19)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #4
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Aeon Labs Temperature (188.8.131.52)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #5
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Aeon Labs Luminiscence (184.108.40.206)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Aeon Labs Humidity (220.127.116.11)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Everspring Humidity (10.0.49.5)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #8
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Chromatic Technologies General purpose (18.104.22.168)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #9
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Fibar Group General purpose (22.214.171.124)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #10
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Aeon Labs General purpose (126.96.36.199)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Fibar Group (11.0.0) Button
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Switch (14.0)
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  node #18
2020-10-03 11:13:33.482 luup_log:23: ZWay: Room 101:  Switch (17.0)
2020-10-03 11:13:33.482 openLuup.luup:: device 23 'ZWay' requesting reload
rafale77 last edited by
I can second AK in saying I can't reproduce this. Deleting the device on openluup + luup reload has actually been the mechanism we used to reset configuration of errant devices because it recreates it.
I'm reinstalling everything again. I'll report back in a few.