Yes, that looks like a general purpose binary sensor.
I’ve changed the appropriate device attributes:
[ul][li]device_file to D_DoorSensor1.xml[/li]
[li]device_json to D_DoorSensor1.json[/li][/ul]
for a similar sensor on my development machine and that has the desired effect.
Is there any way to get this virtual button push in Z-way to somehow trigger a scene in openLuup? This is from a HomeSeer dimmer with a 2 button push:
[2016-12-10 19:14:14.088] [D] [zway] RECEIVED: ( 01 0B 00 04 00 09 05 5B 03 13 03 01 B5 )
[2016-12-10 19:14:14.088] [D] [zway] SENT ACK
[2016-12-10 19:14:14.088] [D] [zway] SETDATA controller.data.incomingPacket.nodeId = 9 (0x00000009)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA controller.data.incomingPacket.frameType = "singlecast"
[2016-12-10 19:14:14.088] [D] [zway] SETDATA controller.data.incomingPacket = **********
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.9.data.lastReceived = 0 (0x00000000)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.9.instances.0.commandClasses.91.data.sequence = **********
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.1.instances.0.commandClasses.91.data.srcNodeId = 9 (0x00000009)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.1.instances.0.commandClasses.91.data.srcInstanceId = 0 (0x00000000)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.1.instances.0.commandClasses.91.data.keyAttribute = 3 (0x00000003)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.1.instances.0.commandClasses.91.data.currentScene = 1 (0x00000001)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.9.instances.0.commandClasses.91.data.keyAttribute = 3 (0x00000003)
[2016-12-10 19:14:14.088] [D] [zway] SETDATA devices.9.instances.0.commandClasses.91.data.currentScene = 1 (0x00000001)
[2016-12-10 19:14:14.106] [I] [core] Notification: device-info (device-OnOff): {"dev":" (9.0.0.1) Button","l":"on"}
Ideally there would be some way to know the keyAttribute since that changes based on how many times the button is pushed. Also, the button is never turned off - if the opposite side of the paddle is pushed, button 9.0.0.2 gets the “on” instead of 9.0.0.1. As far as I can tell no “off” is ever sent. So I need some way to detect this message and act on it without depending on the state of this device.
thanks
One more question on this: is there a way to see the virtual devices in Z-way in openLuup? That would also be useful although it doesn’t solve the problem above since they don’t seem to see the keyAttribute. Thanks.
[quote=“jswim788, post:22, topic:193746”]Is there any way to get this virtual button push in Z-way to somehow trigger a scene in openLuup? This is from a HomeSeer dimmer with a 2 button push:
[…]
Ideally there would be some way to know the keyAttribute since that changes based on how many times the button is pushed. Also, the button is never turned off - if the opposite side of the paddle is pushed, button 9.0.0.2 gets the “on” instead of 9.0.0.1. As far as I can tell no “off” is ever sent. So I need some way to detect this message and act on it without depending on the state of this device.[/quote]
Indeed, it seems that the ZWay Virtual device interface, doesn’t report the value of some switches. What I have tried to do, in some cases, is to update the “LastTrip” variable with the time of the change. This way, you can, at least, trigger a scene.
My approach with the ZWay plugin has been to try and emulate the arrangement of devices which Vera shows when presented with the same ZWave device. This, however, turns out to be hard, if not impossible, in any generic way, and it seems as though Vera has a large look-up table, manufacturer dependent, to define how it should look. So, at the moment, the emulation is imperfect to say the least.
Having said that, your question prompts to to investigate further the initial thoughts I had for this interface, and that would be simply to echo the appearance of the ZWay virtual device interface. This leads to single devices presenting individual sensors as separate (child?) devices. It would seems to be a much more straight-forward approach and I might give that a go in the next few weeks. It would means that things would be less Vera-like, but so what?
However, it does also seem that the ZWay Virtual Device API is both incomplete and imperfectly implemented, so some things just don’t seem to work from their own software. However, perhaps we can hope that this improves in time (faster than Vera’s firmware does.)
My approach with the ZWay plugin has been to try and emulate the arrangement of devices which Vera shows when presented with the same ZWave device. This, however, turns out to be hard, if not impossible, in any generic way, and it seems as though Vera has a large look-up table, manufacturer dependent, to define how it should look. So, at the moment, the emulation is imperfect to say the least.
I think I am facing same issue with my Domoticz bridge… no perfect match at all but I became impressed with openZwave embedded into Domoticz… up to date with new devices and though it does not yet support scene controllers, even Fibaro Buttons work well through associations… That’s why I am spending a lot of efforts right now at making my DomoticzBridge plugin more robust. …
I think it would be helpful to be able to see and access the child devices as in Z-way, but I agree it’s not perfect. In this particular case, as far as I can tell, Z-way doesn’t retain the keyAttribute anywhere, so I did the ugly brute force approach and created a script that tails the Z-way log file and watches for the central scene command class messages to float by. It works…
Has anyone tried the new v2.3.0 Z-way code? It adds central scene keyAttribute via an ‘n-state’ vDev - this will be very useful with Homeseer switches and other other switches that support central scene.
I upgraded to 2.3.0 (was 2.2.3) last Saturday. It’s an improvement (stable) and it seems to have resolved the interview issue (having to re-interview specific devices after a set period of time) but I can’t see any state changes for locks and GE binary/dimmer switches (which I was using Niffler). PoltoS is/was looking into it, logs submitted and he indicated he would implement differently which leads me to believe they have more developers assisting with code.
I must give this a go … was waiting for favourable reports for the update!
AK,
Hope all is well, I haven’t been on as much lately due to work and our re-org/management shakeup (it’s been insane)… Yes, 2.3.0 has lots of changes and fixes. Just make sure to backup the z-wave network beforehand. I’ve only been using this release for a week but so far so good as I can live with the locks not giving a status update (can still control them though). The ExpertUI is now sluggish (e.g Routing) but it’s rare to have visit that area. Perhaps they’ll perform a maintenance release and things will be near perfect. Did you end up upgrading to V2 of the board?
–CN
Hi there. Yes, all OK, except that my Arduino Yun has just given up the ghost. So now looking at putting a MySensors gateway natively on the RPi or BBB before I can play with 2.3.0. No, didn’t get the latest board, yet.
Still thinking about refactoring the ZWay plugin to simply mirror the simple interface rather than trying to emulate Vera so much. Your thoughts?
So what exactly is happening to the Arduino? I’m curious as I want to start using them to manage my ductless units (pretty cool write up by someone on here) - also WAY cheaper than buying Mitsubishi thermostats and wireless controller ($250 USD) for each unit. I can say that all of my RPI’s are still running strong but in fairness, you’ve had that Arduino way longer than any of my Pi’s…
As for refactoring, I’m all in… I think it’s a great idea … Just let me know how I can help…
–CN
[quote=“akbooer, post:31, topic:193746”]@CudaNet
Hi there. Yes, all OK, except that my Arduino Yun has just given up the ghost. So now looking at putting a MySensors gateway natively on the RPi or BBB before I can play with 2.3.0. No, didn’t get the latest board, yet.
Still thinking about refactoring the ZWay plugin to simply mirror the simple interface rather than trying to emulate Vera so much. Your thoughts?[/quote]
The problem seem to be with the Atheros processor on the Yun board, not the actual Arduino chip itself. (There’s a fizzing sound when the power is applied… not good!)
All of my other MySensor devices with mini- and nano- Arduinos are rock solid, and have been since the day I built/installed them.
The Yun board was convenient because it could run both the gateway and openLuup on the two separate processors. But now things have moved on: you can’t buy a Yun here in Europe, and you can now directly connect a radio to the RPi.
The new Zway 2.3.0 supports central scene through virtual devices that have the ‘metrics.level’ (see [url=https://forum.z-wave.me/viewtopic.php?f=3419&t=24449#p67128]Central scene - keyAttribute? - forum). Can we get that exposed through the Zway plugin? Thanks.
Ooh, that sounds interesting. I’ll take a look.
Many thanks for that, I’ll go ahead and move forward with the Arduino.
The problem seem to be with the Atheros processor on the Yun board, not the actual Arduino chip itself. (There’s a fizzing sound when the power is applied… not good!)
All of my other MySensor devices with mini- and nano- Arduinos are rock solid, and have been since the day I built/installed them.
The Yun board was convenient because it could run both the gateway and openLuup on the two separate processors. But now things have moved on: you can’t buy a Yun here in Europe, and you can now directly connect a radio to the RPi.[/quote]
Just a quick update…
PoltoS confirmed they’ll look into the lock issue (which they introduced; Schlage and Yales) but I’m concerned for others who may be using Niffler for GE/Jasco products. I’ve been slowly moving all my Jasco switches over to my parents house and opting for Leviton’s with instant status.
Aside from that, 2.3.0 is very stable… I’ve not had to re-interview devices (a terrible bug) so that’s good news. IF only they’d correct Niffler and lock support…
–CN
[quote=“CudaNet, post:28, topic:193746”]I upgraded to 2.3.0 (was 2.2.3) last Saturday. It’s an improvement (stable) and it seems to have resolved the interview issue (having to re-interview specific devices after a set period of time) but I can’t see any state changes for locks and GE binary/dimmer switches (which I was using Niffler). PoltoS is/was looking into it, logs submitted and he indicated he would implement differently which leads me to believe they have more developers assisting with code.
Ooh, that sounds interesting. I’ll take a look.[/quote]
Just wondering if you had a chance to look at the central scene activity from the virtual devices in Z-way 2.3.0? Thanks!
I did upgrade but am yet to look seriously at it. At the same time I also transferred by MySensors gateway to the RPi and that’s giving me a bit of grief.
What’s the easiest way to set up a test for this, do you think?
Note that Z-way 2.3.1 is now out. Looks like they fixed the lock problem reported by @CudaNet: v2.3.1 is out! - forum
Best Home Automation shopping experience. Shop at Ezlo!
© 2024 Ezlo Innovation, All Rights Reserved. Terms of Use | Privacy Policy | Forum Rules