Closed GoogleCodeExporter closed 8 years ago
Hi,
@Ben:
Great to hear that the stick doesn't lose its associations. Perhaps I'll do an
update too. But the binding tells me that my stick has the version 3. Perhaps
this is where Jan has got his information from?
@Roher:
You can avoid your stick from getting other device names/files by using an
'udev rule'. For that just create or add to existing file
(/etc/udev/rules.d/60-usb-serial.rules) a rule like the following:
#zwave
SUBSYSTEMS=="usb", KERNEL=="ttyUSB*", \
ATTRS{idVendor}=="ID_VENDOR_ID", ATTRS{idProduct}=="ID_MODEL_ID", ATTRS{serial}=="ID_SERIAL_SHORT", \
SYMLINK+="zwave0", GROUP="tty", MODE="0666"
For the information you need type in the following:
"sudo udevadm info -q all -n /dev/ttyUSB2"
as ttyUSB2 as your stick file.
There you can find the "ID_VENDOR_ID", "ID_MODEL_ID" and the "ID_SERIAL_SHORT".
Replace these IDs in the rule and save the file. Now your sitck should always
be recocgnised as "/dev/zwave0".
Don't forget to add the following line to your start/start_debug script:
"-Dgnu.io.rxtx.SerialPorts=/dev/zwave0"
(if you are using more serial devices seperate them by using a ":" after the
"=" and the first device.
Best,
André
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 8:01
My logs look the same before and after the upgrade.
2013-09-13 08:15:27 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01
2013-09-13 08:15:27 DEBUG o.o.b.z.i.p.ZWaveController[:585]- API Version = 3.7
Does this mean the upgrade didn't work? According to what I downloaded it
should have updated to 3.07.
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 8:13
Hi,
the info for my stick looks the same as yours. But I haven't upgraded yet.
"2013-09-17 11:44:03 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01"
But the version shown in HABdroid/openHAB is 3.
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 8:17
@André:
Thank you, but unfortunalely it doesn't work for me:
I've tried the same trick with the permanent symlink that udev has created
automatically:
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port
0
And when I put
-Dgnu.io.rxtx.SerialPorts=/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Ser
ial_Controller_D-if00-port0
into java args, and put the same string into z-wave config in openhab.cfg, the
binding crashes when trying to open the device with the following log:
=======================================================
12:19:48.053 INFO o.o.b.z.i.p.ZWaveController[:128] - Starting Z-Wave
controller
12:19:48.053 INFO o.o.b.z.i.p.ZWaveController[:627] - Connecting to serial
port
/dev/serial/by-id/usb-Prolific_Technology_Inc._USB-Serial_Controller_D-if00-port
0
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0xb4ad33ee, pid=7251, tid=2396609392
#
# JRE version: 6.0_18-b18
# Java VM: OpenJDK Client VM (14.0-b16 mixed mode linux-x86 )
# Derivative: IcedTea6 1.8.13
# Distribution: Debian GNU/Linux 6.0.4 (squeeze), package 6b18-1.8.13-0+squeeze2
# Problematic frame:
#
[error occurred during error reporting (printing problematic frame), id 0xb]
# An error report file with more information is saved as:
# /opt/openhab/hs_err_pid7251.log
#
# If you would like to submit a bug report, please include
# instructions how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
Aborted
=======================================================
and creates the file hs_err_pid7251.log, which I have attached to my message.
I'll try to create my own symlink as I have described above, but I think there
is no difference.
@JWSP:
IMHO, it is a real situation when a user can just remove the stick from his/her
PC when OpenHAB is running. My changing port just emulates this situation. And
it should not lead to crashing of the whole OpenHAB server. Of course, Z-Wave
binding will stop, but OpenHAB itself should continue working.
Original comment by roher.ro...@gmail.com
on 18 Sep 2013 at 8:29
Attachments:
I just re-ran the upgrade on my stick for 3.07 and it all completed
successfully. However after restarting the binding I am still seeing;
2013-09-18 20:33:34 DEBUG o.o.b.z.i.p.ZWaveController[:445]- Got
MessageGetVersion response. Version = Z-Wave 2.78, Library Type = 0x01
Will be interested to hear if anyone else has any luck with this.
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 8:35
@Ben:
I can't test right now, but will try it this week hopefully.
@Roher:
Weird thing. I don't have any problems with my symlink. Perhaps it is because
Jave expects a file which is located under /dev directly? I don't know whether
it could be the problem. Perhaps it's worth to try my example? At least it
couldn't get worse :)
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 8:45
@André:
Yes, your solution works! I don't know what is the difference, but it works!
Thank you very much!
Original comment by roher.ro...@gmail.com
on 18 Sep 2013 at 9:27
Ben, I was just assuming that that version number was the stick software
version number, because that is what it should report i guess.
But who knows, maybe they forgot to update this number, or it is another
version number. If the utility says succeeded, it probably did.
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 9:32
@Roher:
Great to hear :)
@Jan:
Perhaps it is the number of the zwave protocol which the stick uses?
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 9:39
The serial api version number is returned from serial_api_get_capabilities and
reports 3.7 in the case of Ben.
Z-Wave version numbers is a mess ;-)
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 10:39
Yep - as long as my lights turn on when they are supposed to I am happy!
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 11:36
fully agree :)
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 11:41
So what is next JwS? Everything is running pretty sweet on my setup now. I have
some dimmer modules arriving tomorrow which I will install soon (once I get the
new wall switch modules).
I now don't have any polling since all state changes (manual) are being handled
by the binding - which means a much more manageable log file! I am getting next
to no errors or warnings apart from the odd timeout etc. Initialisation is
pretty solid, I occaisionally get a few errors which usually go away after a
restart.
I am very happy with the state of the binding as it stands - so thanks very
much for all your help! This thing is definitely ready for prime time.
For reference - I have a Aeotec USB Z-Stick, 1 x Aeotec Micro Smart Energy
Switch, 5 x Fibaro 2x1.5kW relays, 1 x Door Sensor (with temp sensor), and 1 x
Universal Sensor (with temp sensor).
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 11:52
[deleted comment]
@Jan:
where did you buy the greenwave (schuko) power bar? I searched the web but
found nothing. But the device sounds very interesting.
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 12:34
Actually I got it from somebody who was testing the hardware for one of the
energy companies in the Netherlands. They offer these devices with proprietary
controllers, but they are just regular Z-Wave devices.
Nuon has a webshop that sells them, but I doubt to foreigners.
http://www.nuonenergiewinkel.nl/7591/smart-plug-6-voor-nuon-e-manager
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 1:31
Hi,
I think you are right. I'll search for others.
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 1:42
I have this feeling that they partner with OEMs to try and sell their stuff.
This makes it probably harder to get them.
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 1:50
@Ben:
Well, I have a smoke alarm, a sirene, thermostats and a multi-sensors waiting
to be installed. They probably have command classes that we don't support yet.
I was thinking about implementing Security and CRC_16 as well. I have devices
now that support these command classes.
Finally I'm thinking of implementing the "optimize network" functionality
similar to e.g. homeseer (request neighbor updates, remove return routes,
assign return routes, rinse, repeat).
Original comment by jwsp...@gmail.com
on 18 Sep 2013 at 2:37
Great to here. I'm waiting for my new devices, a siren and a window/door
contact to arrive and of course to be installed. :)
Original comment by DerRo...@gmail.com
on 18 Sep 2013 at 2:41
Yeah I think the next thing I really want is a ZWave door lock, would round off
my home security automation nicely. So I would put a big vote in for
security/lock etc support. Do you have a lock ready for testing?
The network optimisation stuff sounds very useful too - it is a bit of a pain
having to stop everything, run OZWCP to update routes etc, then cross fingers
and toes that the binding will start again!
Original comment by ben.jone...@gmail.com
on 18 Sep 2013 at 8:45
JwS - think I still have one more small issue with the node stage
initialisation stuff. My door sensor (node 9) sometimes fails to initialise
properly. It still receives and process basic reports ok (i.e. door
opening/closing) and the battery reports are coming through ok, but the
temperature readings are failing.
Attached are the logs if you would be so kind as to have a look with your well
trained eye! I have had a look and it seems the node doesn't quite initialise
the multi instance command class for some reason.
I will keep digging but you seem to spot issues in these logs far quicker than
I am ever able to do!
Many thanks,
Ben
Original comment by ben.jone...@gmail.com
on 19 Sep 2013 at 8:11
Attachments:
I think the issue might be in ZWaveWakeUpCommandClass, line 185. Looking in the
logs for node 9 it wakes up and gets to the MANU_SPECIFIC stage where it sends
off version requests for both the WAKE_UP and MULTI_INSTANCE classes (line
4339).
It only receives a response to the first of these version requests (line 4410)
but doesn't get the second response until line 9237. In between that time the
node wakes up (line 6777) and I believe during this wake-up phase the node
stage is being advanced.
Then when the node tries to process the second VERSION message it ignores it
since the node has been advanced past that stage.
Hope this helps!
Original comment by ben.jone...@gmail.com
on 19 Sep 2013 at 9:19
Hi,
my new devices arrived: An Everspring Indoor Siren
(http://products.z-wavealliance.org/products/273) and a Vision Door Sensor
(http://products.z-wavealliance.org/products/702). But right now im not able to
use them with the 1.3.0 binding. My items are like:
Switch Alarm_Sirene "Alarm-Sirene" { zwave="3:1" }
Number Alarm_Sirene_Battery "Alarm-Sirene Batterie [%s]" (gZwaveStats) {
zwave="3:1:battery_level" }
Contact Tuer_Sensor "Tür Sensor [%s]" { zwave="6" }
Number Tuer_Snsor_Battery "Tür Sensor Batterie [%s]" (gZwaveStats) {
zwave="6:1:battery_level" }
Or should I try your new binding where I can state the command_class I want to
use?
Can someone guide me to the right direction? In ozwcp all looks very good.
Besides that I have 4 nodes but my last one does have no. 6, because for
testing I added and removed it from my network. But now I have node 1, 2, 3 and
6. Looks weird.
Best, André
Original comment by DerRo...@gmail.com
on 20 Sep 2013 at 11:19
Could you send me your log please?
Original comment by jwsp...@gmail.com
on 20 Sep 2013 at 12:28
Yes of course :)
forgotten.
Original comment by DerRo...@gmail.com
on 20 Sep 2013 at 12:53
Attachments:
Node 6 is actually OK. The door sensor. The only issue is that it's wake-up
interval is set to 3600 seconds and it takes two cycles to initialize, so it
will probably take 2 hours before it starts working. You could shorten the
interval to 5 minutes at the expense of battery life. Once the binding supports
restoring the node info from config, this is not necessary anymore.
Now node 3 is a flirs device and currently we don't support flirs devices yet,
but as I have the same alarm, it probably will not take too long.
Original comment by jwsp...@gmail.com
on 20 Sep 2013 at 1:31
Ah. Didn't know that. I noticed the 3600 seconds in ozwcp, but thought it would
be a good value.
For the flirs device I could and should update to the new binding. But I will
wait for it :)
Thanks for your help!
Original comment by DerRo...@gmail.com
on 20 Sep 2013 at 1:45
3600 seconds is a good value if your network is stable and you don't restart
openHAB very often. If you're like me, play a lot with your setup, then i'd
reduce it and stock up on some batteries ;-)
Original comment by jwsp...@gmail.com
on 20 Sep 2013 at 2:55
There is another option: usually a button sequence will keep the node awake for
15 minutes or so to allow this kind of initialization. So you could activate
your node before starting openhab.
Original comment by jwsp...@gmail.com
on 20 Sep 2013 at 2:56
Battery stock is fine :)
You are right. I really often restart my openHAB, because of playing with the
setup.
Original comment by DerRo...@gmail.com
on 20 Sep 2013 at 3:03
Hi,
I've got a question concerning my door sensor. Perhaps it is a general zwave
network question.
I noticed that the value of the status in ozwcp of the integrated reed contact
only updates the times the device wakes up. Nevertheless the value of "Last
Heard" updates every time I move the magnet from or to the device. But then I
cannot see the sensor value being updated.
Isn't it enough to include the device to the network? Do I have to do more?
Thanks.
Best, André
Original comment by DerRo...@gmail.com
on 21 Sep 2013 at 4:39
Sounds like it is fine. You might need to enable basic report handling as my
FIBARO door sensor only sends BASIC reports. See the WIKI for details on how to
configure that. But the device will send reports before it is properly
initialised so it will be obvious it is working right away.
Original comment by ben.jone...@gmail.com
on 21 Sep 2013 at 8:30
JwS - did you see my comment #123? Think there is something not quite right but
I am not certain of the best way to fix it. Is it as simple as removing the
nodeAdvance() call in the WakeUp class?
Original comment by ben.jone...@gmail.com
on 21 Sep 2013 at 8:32
Thank you Ben. You guided me in the right direction. I changed my item from
"contact" to "switch" and now my rule works pretty well :)
For testing I added a new item which uses basic reports and it reports on every
change "0x04". What is weird is when I have a look in the lock I see the states
OPEN and CLOSED too. Well, now everything seems to work fine.
Does anybody know whether I can remove groups which I added for playing in
ozwcp without removing the whole device?
Original comment by DerRo...@gmail.com
on 21 Sep 2013 at 9:48
Ben, I'll try and look at it soon. Pretty busy with my day job ;-)
Original comment by jwsp...@gmail.com
on 24 Sep 2013 at 9:02
I hear ya mate!
Original comment by ben.jone...@gmail.com
on 24 Sep 2013 at 9:11
Ben, I think i've fixed #123. It's in my github clone.
Original comment by jwsp...@gmail.com
on 27 Sep 2013 at 6:17
BTW, I've deleted the google code clone. All code with history is in my github
repository.
Original comment by jwsp...@gmail.com
on 27 Sep 2013 at 6:18
DerRocka,
I've started working on the Siren. I have it myself as well. Turned it on
today, 100db is quite loud ;-)
Anyway, I first have to clean up some classes because they got over a 1000
lines, but i'll try and finish it this weekend.
Original comment by jwsp...@gmail.com
on 27 Sep 2013 at 8:19
Great to hear. You are right...100db are quite loud. First I had it less loud
but I thought this couldn't be heard 1 or 2 floors up or down, so I left it at
100 db :-)
I would love to help you programming, but I haven't set up the development
environment yet and fear that I don't understand enough of the ZWave protocol
internals to be a really good help at the moment.
Thank you anyway :-)
Original comment by DerRo...@gmail.com
on 27 Sep 2013 at 11:02
JwS - thanks for fixing that issue - I am trying to figure out how to pull your
changes so I can compile and test. I gotta say, this GitHub is taking some
getting used to!
Original comment by ben.jone...@gmail.com
on 28 Sep 2013 at 9:15
Hi,
I have some question, remarks:
- I got an exception where most information where lost:
2013-09-27 09:17:55 INFO o.o.b.z.i.p.ZWaveController[:627]- Connecting to
serial port /dev/ttyAMA0
2013-09-27 09:17:56 ERROR o.o.b.z.i.p.ZWaveController[:642]- null
According to the debugger / code it is NoSuchPortException where no other
information are attached. For that case a more detailed information somewhere
would be nice. I havent been able to find the SerialInterfaceException somehow.
A symlink of /dev/ttyAMA0 to a ttyS80 interface worked fine as workaround.
- Is the "Eurotronic StellaZ" Thermostat supported via the basic command class?
Do you have experience with other thermostats?
Thanks!
Lars
Original comment by lars.pfa...@gmail.com
on 28 Sep 2013 at 3:04
Hi Lars,
I believe I had that null exception when I forgot to add the line for the
symlink in the startup script. Did you add that?
André
Original comment by DerRo...@gmail.com
on 28 Sep 2013 at 4:09
Yep check the wiki for instructions about how to configure openhab to recognise
symlinks. The io library used doesn't support symlinks directly.
Original comment by ben.jone...@gmail.com
on 28 Sep 2013 at 7:38
Hi,
@André: yes, the link will is created at boot time.
@Ben: AMA0 is not a symlink and the (on boot created) symlink works out of the
box. So no need for a wiki reading session ;)
But I would like to point out my main question: Has someone experience with
zwave thermostats? Since the thermostat setpoint device class appears under a
"high priority" feature for 1.4 I would assume that there must be someone
telling me which thermostats should work. The only 2 thermostats I can find so
far is the danfoss 014G0012 and the Eurotronic StellaZ.
Lars
Original comment by lars.pfa...@gmail.com
on 29 Sep 2013 at 12:36
Apologies Lars - did look closely enough at your logs. As for the thermostat
device, I don't think this has been implemented yet. JwS and I have only been
adding support for devices we own and can test. If you get your hands on a
thermostat then perhaps you could have a go at developing the command class
support for it?
Original comment by ben.jone...@gmail.com
on 29 Sep 2013 at 7:17
Actually I ordered the StellaZ, so expect support for it soon. I think it will
work with the basic command class as well for setting temperatures. Don't
expect reading the measured temperature though.
I ordered the StellaZ instead of the Danfoss because it fits nicely on my jaga
convectors (no adapter needed) and I heard some horrible stories about Danfoss
and Z-Wave compatibility.
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 7:21
Reading temperature will be supported once we support the thermostat* command
classes.
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 7:22
Great stuff - looking forward to seeing the ZWave family growing ;).
Original comment by ben.jone...@gmail.com
on 29 Sep 2013 at 7:22
Original issue reported on code.google.com by
jwsp...@gmail.com
on 2 Sep 2013 at 12:45