Hello,
it seems that there is a new plugin in developpement for Z-Way : GitHub - akbooer/Z-Way: Zway plugin for openLuup
Is it the new Razberry plugin ?
[quote=“vosmont, post:1, topic:193746”]it seems that there is a new plugin in developpement for Z-Way : GitHub - akbooer/Z-Way: Zway plugin for openLuup
Is it the new Razberry plugin ?[/quote]
No, it’s not the RAZB plugin that @amg0 (and also me, a little bit) had been working on. However, it IS the plugin which @CudaNet has graciously been testing. As of today, the latest openLuup development branch supports the ZWay plugin and you can load it simply by pressing the Update button corresponding to it on the Plugins page.
So let’s be clear: this is NOT a competition. The Razberry board (and also the UZB stick which will plug into any USB port) actually has several UIs and APIs. I’ve chosen to go the cheap, cheerful, and ultimately limited route by using the ‘Virtual Device’ interface that’s also used by the ZWay ‘smarthome’ interface. The RAZB plugin uses the lower-level interface to access the ZWave stack more directly. Ultimately, this can be much more independent of the ZWave.me software suite, and accesses the fullest detail possible, allowing configuration control, etc. of the ZWave network, when @amg0 has the time to work on it.
Sticking with the ZWay plugin, then, it’s entirely dependent on the ZWay software for configuring new devices - I’m not planning to put any of that into the plugin. It does its best to make a ‘Vera-like’ stab at presenting multiple sensors and combination devices in the familiar Vera way, but for sundry reasons doesn’t exactly achieve that. There also seem to be some devices which the current software release of the ZWave.me software doesn’t correctly implement - the biggest of these being thermostats. It is, though, under active development and we may reasonably hope (unlike Vera firmware) that this will be fixed in a later release.
Having said that, it seems to do a great job of most other things, and does work for locks, the Fibaro RGBW controller, and also for remotes like the MiniMote. I haven’t finished fleshing out the plugin functionality but it’s very usable, and given the recent problems I’ve had with one of my VeraLites, I’m about to change over to this for all my lighting controls.
Attached is a screenshot of a system with the ZWay plugin and a fair selection of different devices. I’ll split your post and this reply into a new thread so a not to confuse with any further conversation re. @amg0’s RAZB plugin.
I’ve quickly tested the Z-Way plugin.
Some questions : 
- the Fibaro Flood sensor is shown as a motion sensor. Can it be modified ?
- Is there a way to send Z-Wave commands ? I would like to migrate my RGBW Bulbs on openLuup + Razberry, but the RGB Controller plugin does not work, because it sends Z-wave commands.
2016-09-18 18:59:47.027 luup_log:35: ZWay: service/action not implemented: 35.urn:micasaverde-com:serviceId:ZWaveNetwork1.SendDataCan you tell be the altid of the motion detector device that it shows? Does the smarthome interface show it as a flood detector?
- Is there a way to send Z-Wave commands ? I would like to migrate my RGBW Bulbs on openLuup + Razberry, but the RGB Controller plugin does not work, because it sends Z-wave commands.
I thought it only did that for specific animations? Anyway, I’m not sure about this - I’ll have to check the ZWay documentation and see - this may be a case where the full low-level interface is required.
I take it that it all installed OK, then… how are ‘normal’ devices working?
It’s shown as “Fibar Group Water Alarm (2.0.156.5)” in the smarthome interface
- The Switch Everspring AN157 can be controlled but the status is not updated when it is controled by hand (same problem in smarthome interface)
- The Fibaro smoke sensor is shown just as a temperature sensor
- The Zipato ZD2102 door sensor is shown just as a controller
- The Zipato RGBW bulb is shown as a dimmer
For the moment, I’m trying to have the Z-wave devices well recognised in the Z-way interface.
I have to confess that I’m a bit desapointed by Z-Way.
The Smarthome display the subpart of the devices without grouping them, so it’s really difficult to retrieve all the part of a device.
In expert mode, to access configuration, you have to choose a device description… and the list seems to be a bit confused (lots of duplicates, different classifications)
It seems that the problems that I had with some Z-wave devices are still here :
- Zipato ZD2102
- Philio PST02-1A
So no miracles, despite their Z-wave+ certification, these devices implement their features in an oddly way.
Yes, that’s the challenge for the Z-Way gateway plugin. It does its best to group things sensibly (that is to say, like Vera.)
So no miracles, despite their Z-wave+ certification, these devices implement their features in an oddly way.
No, that’s always going to be a problem. Some devices are simply weird.
I’ll try to continue and improve the openLuup representation of some of the devices you mention.
@AK
I have a quick question which I need some guidance on. Here’s my use case, when a door lock state changes (1 to 0), I’d like to perform a query on the type of event (manually unlocked/locked as opposed to unlocked with a code) that transpired as well as obtain the ‘UserCode’ when applicable. When I’m logged into the Z-wave expert UI, I can perform the following:
an example request
http://{ip_address}:8083/ZWaveAPI/Run/devices[dev].instances[0].commandClasses[113].data[6].eventString'
an example response
{"invalidateTime":1475952682,"updateTime":1475973328,"type":"string","value":"Manual Lock Operation"}Obviously this won’t work as I’m not logged (status 401) in. Is this a, ‘don’t dare proceed in that direction’ or ‘sure, no problem - here’s what I’d do’ …
Thanks,
–Cuda
P.S.
I finally was able to include all my Schlage locks and they work great within openLuup/AltUI. Hell, everything is working awesome… I had one little incident whereby a node went rogue on me and took down 9 others behind it… I re-interviewed the fails until the offender was cleared and everything went back to normal. I think I’m up to 30 or so nodes, just taking it slow as I continue testing. I have a lot more to add but I’d like to bring unit #2 back online and see if I can balance things out. I also need to discuss some tweaking on a few things but that can wait - no rush whatsoever…
You’re asking in the context of the Z-Way plugin? … in which case I’ll move this post to that thread.
When I'm logged into the Z-wave expert UI, I can perform the following [...] Obviously this won't work as I'm not logged (status 401) in. Is this a, 'don't dare proceed in that direction' or 'sure, no problem - here's what I'd do' ....
Well, this sounds like something the plugin should do for you. Not having any locks myself (on a Vera) I don’t know the expected behaviour of interesting device variables.
However, for the purposes of testing, it should be simple enough for me to construct a way to use the plugin’s authorization as a proxy for any request you like to the advanced API. Perhaps I can simply add an action to the plugin which will take any GET HTTP request line and return its output.
I finally was able to include all my Schlage locks and they work great within openLuup/AltUI. Hell, everything is working awesome...
Oh, excellent… always delighted to hear that sort of response.
I think I'm up to 30 or so nodes, just taking it slow as I continue testing. I have a lot more to add but I'd like to bring unit #2 back online and see if I can balance things out. I also need to discuss some tweaking on a few things but that can wait - no rush whatsoever...
So nearly a total Vera replacement , then? Sorry that I haven’t really got back into this after my vacation. I’ve also been having too much fun with DataYours, switching the dashboard from my home-grown disaster, to the truly excellent Grafana.
This sounds perfect, once I’m able to identify the exact classes that are common across the two manufacturers - I’ll provide an update. Perhaps it’s something that can be implemented in the future for those with locks which trigger off of specific users and specific lock events. Right now we are left with just the status of the lock which reminds me. It appears the time/date of the state change isn’t reflected. In fact, I’m not sure what the date/time being displayed on the tile means. You still have full access to the system if you need to take a look.
Well, this sounds like something the plugin should do for you. Not having any locks myself (on a Vera) I don't know the expected behaviour of interesting device variables.However, for the purposes of testing, it should be simple enough for me to construct a way to use the plugin’s authorization as a proxy for any request you like to the advanced API. Perhaps I can simply add an action to the plugin which will take any GET HTTP request line and return its output.
ABSOLUTELY ! I still have a brand new Vera Plus sitting in a box and I don’t plan on opening it anytime soon (might gift it to my sister though). Your vacation allowed me to take some time and really get a feel for things and how well the devices were operating with the Razberry board. I will say that if at all possible (perhaps this is a Amg0 thing) it would be great if a node fails, to have the tile change to red or an icon denoting a failure with a date/time stamp. This way we could easily identify who the 1st offending node was that failed. Easier said than done though.
So nearly a total Vera replacement , then? Sorry that I haven't really got back into this after my vacation.
I just had a look at Grafana, how cool is that … Nice !
I've also been having too much fun with DataYours, switching the dashboard from my home-grown disaster, to the truly excellent Grafana.
As always, a huge thanks !
–Cuda
The latest GitHub version of the plugin has a required change to support the following…
If you add the attached file as /etc/cmh-ludl/cgi/port_8083 (NB. without the .lua extension that I had to put on the attachment) then you can use, for example, the following syntax for any request to the native ZWay interface(s)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Data/*or, indeed, your original request (obviously doesn’t work on my system)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Run/devices[dev].instances[0].commandClasses[113].data[6].eventStringor, use the virtual devices interface
http://openLuupIP:3480/cgi/port_8083?ZAutomation/api/v1/devicesor whatever.
This should enable you to do what you need until we find a better way to integrate this into the ZWay plugin. Do tell how it works for you.
Greatness… I’ll backup my installation today and load the latest files and report back… Much appreciated !
[quote=“akbooer, post:10, topic:193746”]@CudaNet
The latest GitHub version of the plugin has a required change to support the following…
If you add the attached file as /etc/cmh-ludl/cgi/port_8083 (NB. without the .lua extension that I had to put on the attachment) then you can use, for example, the following syntax for any request to the native ZWay interface(s)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Data/*or, indeed, your original request (obviously doesn’t work on my system)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Run/devices[dev].instances[0].commandClasses[113].data[6].eventStringor, use the virtual devices interface
http://openLuupIP:3480/cgi/port_8083?ZAutomation/api/v1/devicesor whatever.
This should enable you to do what you need until we find a better way to integrate this into the ZWay plugin. Do tell how it works for you.[/quote]
Looks like I’m generating an error when I issue the following for device 39:
http://{myIpAddress}:3480/cgi/port_8083?ZWaveAPI/Run/devices[39].instances[0].commandClasses[113].data[6].eventString./openLuup/wsapi.lua:112: attempt to index local 'line' (a nil value)[quote=“akbooer, post:10, topic:193746”]@CudaNet
The latest GitHub version of the plugin has a required change to support the following…
If you add the attached file as /etc/cmh-ludl/cgi/port_8083 (NB. without the .lua extension that I had to put on the attachment) then you can use, for example, the following syntax for any request to the native ZWay interface(s)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Data/*or, indeed, your original request (obviously doesn’t work on my system)
http://openLuupIP:3480/cgi/port_8083?ZWaveAPI/Run/devices[dev].instances[0].commandClasses[113].data[6].eventStringor, use the virtual devices interface
http://openLuupIP:3480/cgi/port_8083?ZAutomation/api/v1/devicesor whatever.
This should enable you to do what you need until we find a better way to integrate this into the ZWay plugin. Do tell how it works for you.[/quote]
OK, plan B (even better, might actually work, it does for me, but, there again, so did plan A) …
[ol][li]update openLuup from the development branch[/li]
[li]add the attached file as /etc/cmh-ludl/cgi/zway_cgi.lua (NB. with the .lua extension)[/li]
[li]delete /etc/cmh-ludl/cgi/port_8083[/li][/ol]
Now, any Zway-related requests made to port 3480 are simply relayed to the ZWay interface on port 8083, no special syntax required.
http://openLuupIP:3480/ZWaveAPI/Run/devicesBetter luck this time.
Entirely my fault, I looked at the file size of the image I posted and duh ! Looks like I downloaded the port_8083 to a file within a folder (same name, don’t do that) and copied that over to the instance. It was the 4096 (size) that gave it away so yes, Plan A does indeed work. Me on the other hand… No workie !
And this is what we wanted…
0 {"invalidateTime":1475952682,"updateTime":1476707924,"type":"string","value":"Manual Lock Operation"} 200Many apologies for that one…
[quote=“akbooer, post:13, topic:193746”]OK, plan B (even better, might actually work, it does for me, but, there again, so did plan A) …
[ol][li]update openLuup from the development branch[/li]
[li]add the attached file as /etc/cmh-ludl/cgi/zway_cgi.lua (NB. with the .lua extension)[/li]
[li]delete /etc/cmh-ludl/cgi/port_8083[/li][/ol]
Now, any Zway-related requests made to port 3480 are simply relayed to the ZWay interface on port 8083, no special syntax required.
http://openLuupIP:3480/ZWaveAPI/Run/devicesBetter luck this time.[/quote]
Plan B workie too?
…you don’t have to delete the port_8083 file if you want to retain that for the moment.
Works perfectly ! This event shows the lock being locked from the outside keypad when I left for the office this morning…
0 {"invalidateTime":1475762555,"updateTime":1476716350,"type":"string","value":"Keypad Lock Operation"} 200[quote=“akbooer, post:15, topic:193746”]Plan B workie too?
…you don’t have to delete the port_8083 file if you want to retain that for the moment.[/quote]
Just had to drop in and say that I’m really loving the solution you provided here… I’ve been able to isolate a lot of features that weren’t available to me on Vera. I’ll provide a more detailed write-up for those who have a Schlage and Yale unit once I’ve had more time.
How does this Zway plugin determine if a sensor is a motion sensor or a door/window sensor? I have an Ecolink Door/Window Sensor (DWZWAVE2-ECO) that is seen as a motion sensor. Did it get some information from the Zway server to make it think it is a motion sensor? If so, what? And is there any harm in changing the attributes for the device to the door sensor to resolve this? I can’t see anything on the Zway side to change to resolve this. It seems to see the sensors as binary sensors.
It uses the same ZWay API as the smarthome web interface (ie. not the advanced one.)
I have an Ecolink Door/Window Sensor (DWZWAVE2-ECO) that is seen as a motion sensor. Did it get some information from the Zway server to make it think it is a motion sensor? If so, what?
If the smarthome interface shows it as a motion sensor, then there may be nothing the plugin itself can do about it. However, to make sure, if you post the output of this URL:
http://openLuupIP:3480/data_request?id=lr_zNNN…replacing openLuupIP with your system’s IP and NNN with the device number of the ZWay plugin, then I can ascertain is there’s something we can do about it.
And is there any harm in changing the attributes for the device to the door sensor to resolve this? I can't see anything on the Zway side to change to resolve this. It seems to see the sensors as binary sensors.
No harm at all in changing the device_file attribute to a door sensor AFAIK.
Here’s the sensor of interest using the lr_z5 request as you mention (full output below). Is this device wrongly identifying itself as a motion sensor?
{
“creationTime”:1476330511,
“creatorId”:1,
“deviceType”:“sensorBinary”,
“h”:-1248874786,
“hasHistory”:false,
“id”:“ZWayVDev_zway_3-0-48-1”,
“location”:1,
“metrics”:{
“icon”:“motion”,
“level”:“off”,
“probeTitle”:“General purpose”,
“scaleTitle”:“”,
“title”:“Garage Door Sensor”
},
“permanently_hidden”:false,
“probeType”:“general_purpose”,
“tags”:[],
“updateTime”:1477921114,
“visibility”:true
}
Full output of the command in case it helps:
[{
“creationTime”:1476043513,
“creatorId”:7,
“deviceType”:“battery”,
“h”:-592588978,
“hasHistory”:false,
“id”:“BatteryPolling_7”,
“location”:0,
“metrics”:{
“level”:100,
“probeTitle”:“Battery”,
“scaleTitle”:“%”,
“title”:“Battery digest 7”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477813556,
“visibility”:true
},{
“creationTime”:1476330581,
“deviceType”:“switchControl”,
“h”:1320850420,
“hasHistory”:false,
“id”:“ZWayVDev_zway_Remote_3-0-0-B”,
“location”:0,
“metrics”:{
“change”:“”,
“icon”:“”,
“level”:“on”,
“title”:" (3.0.0) Button"
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477921056,
“visibility”:true
},{
“creationTime”:1477445425,
“creatorId”:5,
“deviceType”:“text”,
“h”:-1261400328,
“hasHistory”:false,
“id”:“InfoWidget_5_Int”,
“location”:0,
“metrics”:{
“icon”:“app/img/logo-z-wave-z-only.png”,
“text”:“If you still want to use ExpertUI please go, after you are successfully logged in, to
Menu > Devices > Manage with ExpertUI
or call
http://MYRASP:8083/expert
in your browser.
You could hide or remove this widget in menu
Apps > Active Tab. ”,
“title”:“Dear Expert User”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477445425,
“visibility”:true
},{
“creationTime”:1476330511,
“creatorId”:1,
“deviceType”:“sensorBinary”,
“h”:-1248874786,
“hasHistory”:false,
“id”:“ZWayVDev_zway_3-0-48-1”,
“location”:1,
“metrics”:{
“icon”:“motion”,
“level”:“off”,
“probeTitle”:“General purpose”,
“scaleTitle”:“”,
“title”:“Garage Door Sensor”
},
“permanently_hidden”:false,
“probeType”:“general_purpose”,
“tags”:[],
“updateTime”:1477921114,
“visibility”:true
},{
“creationTime”:1476330512,
“creatorId”:1,
“deviceType”:“battery”,
“h”:-40289343,
“hasHistory”:false,
“id”:“ZWayVDev_zway_3-0-128”,
“location”:0,
“metrics”:{
“icon”:“battery”,
“level”:100,
“probeTitle”:“Battery”,
“scaleTitle”:“%”,
“title”:“Battery (3.0)”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477813556,
“visibility”:true
},{
“creationTime”:1477108159,
“creatorId”:1,
“deviceType”:“switchBinary”,
“h”:1135708217,
“hasHistory”:false,
“id”:“ZWayVDev_zway_4-0-37”,
“location”:1,
“metrics”:{
“icon”:“switch”,
“level”:“off”,
“title”:“Plug In Power Switch”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477445426,
“visibility”:true
},{
“creationTime”:1477151255,
“creatorId”:1,
“deviceType”:“switchBinary”,
“h”:1164337368,
“hasHistory”:false,
“id”:“ZWayVDev_zway_5-0-37”,
“location”:0,
“metrics”:{
“icon”:“switch”,
“level”:“off”,
“title”:“Porch Light Switch”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477888407,
“visibility”:true
},{
“creationTime”:1477534875,
“creatorId”:1,
“deviceType”:“sensorBinary”,
“h”:-315411077,
“hasHistory”:false,
“id”:“ZWayVDev_zway_6-0-48-1”,
“location”:0,
“metrics”:{
“icon”:“motion”,
“level”:“off”,
“probeTitle”:“General purpose”,
“scaleTitle”:“”,
“title”:“Porch Motion Sensor (6.0.48.1)”
},
“permanently_hidden”:false,
“probeType”:“general_purpose”,
“tags”:[],
“updateTime”:1477888964,
“visibility”:true
},{
“creationTime”:1477534875,
“creatorId”:1,
“deviceType”:“battery”,
“h”:-1672745596,
“hasHistory”:false,
“id”:“ZWayVDev_zway_6-0-128”,
“location”:0,
“metrics”:{
“icon”:“battery”,
“level”:100,
“probeTitle”:“Battery”,
“scaleTitle”:“%”,
“title”:“Battery (6.0)”
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477812946,
“visibility”:true
},{
“creationTime”:1477664447,
“creatorId”:8,
“deviceType”:“switchControl”,
“h”:-311605833,
“hasHistory”:false,
“id”:“ZWayVDev_zway_Remote_6-0-0-B”,
“location”:0,
“metrics”:{
“change”:“”,
“icon”:“”,
“level”:“on”,
“title”:" (6.0.0) Button"
},
“permanently_hidden”:false,
“probeType”:“”,
“tags”:[],
“updateTime”:1477888764,
“visibility”:true
}]