Closed GoogleCodeExporter closed 8 years ago
The only "downside" to the Stella-Z seems to be that it has no manual control.
So your Z-Wave netwprl always needs to work ;-)
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 7:25
I can't see any problem with that...
Original comment by ben.jone...@gmail.com
on 29 Sep 2013 at 7:27
Me neither, but some people have family members that prefer knobs or some other
form of control instead of an i-Phone.
Sometimes I have friends or family staying in my home when we're on holiday:
"No, I don't have knobs on my convectors. But I can turn on the heating from my
holiday address for you." ;-)
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 7:47
I was meaning more that there won't be any issue relying on the ZWave network
being up, now that the binding is so stable ;). But yes - I also have
difficulty explaining to some that it is just so much easier turning on/off
lights using a phone/tablet rather than getting up and flicking the switch...
Original comment by ben.jone...@gmail.com
on 29 Sep 2013 at 7:55
I earlier got some cheap danfoss thermostats on ebay which had a firmware which
is not really z-wave compliant, bad luck. I just ordered some StellaZ
thermostat as well. So I might be interested or on helping on the thermostat
command class.
Original comment by lars.pfa...@gmail.com
on 29 Sep 2013 at 8:13
That's what I mean. There seem to be two types of Danfoss thermostats. One is
more or less Z-Wave compatible the other surely isn't. To make matters worse
they seem to have used the same product no. for a Z-Wave compatible and Z-Wave
incompatible version. The only way to tell the difference is the firmware
version. It seemed a bit to risky ordering one of those when you cannot be sure
that it is Z-Wave compatible.
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 8:23
Your help is more than welcome. Please take the source from my github clone,
branch 1.4.0-zwave and add a thermostat command class. ;-)
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 8:24
Der Rocka,
I've added support for fLIRS (Frequently listening, the siren is such a device)
devices. It's in my fork. I will try and create binaries tomorrow. I've got a
full 100db at my fingertips now ;-) Very cool to play with, although my
neighbours probably won't like it ;-)
Anyway the 1.4.0 binding config for my siren:
Switch Siren_Alarm "Alarm sirene." (GF_Corridor)
{zwave="28:command=switch_binary"}
Number Siren_Alarm_Battery "Alarm sirene batterijniveau [%d %%]" (GF_Corridor)
{ zwave="28:command=battery" }
Original comment by jwsp...@gmail.com
on 29 Sep 2013 at 9:15
JwS - I still get the odd network issue and a node is marked as dead. The only
problem is that even tho the binding reports the node as dead in the log, it
doesn't set the 'dead' flag in the code - or the 'command=INFO,item=DEAD'
binding is never updated.
Original comment by ben.jone...@gmail.com
on 29 Sep 2013 at 9:23
Great and thanks JwS. Can't wait to try the new binaries.
The problem, that the fibaro double switch stops working after few days goes
on. But I hadn't time yet to have a look at the logs, but I will do it.
The door sensor works pretty well.
I have thermostats myself and am using them over a year now, but I am using
them with the control panel of Danfoss. They are working really good. I've
heard of the problem with the inoperability but read that those which came with
the official zwave sign on the box should work in most cases with other
standard controller. I've looked at mine and they have this sign on the box.
But as I said I didn't testet them without the original controller.
Best,
André
Original comment by DerRo...@gmail.com
on 30 Sep 2013 at 8:42
Ben,
Do you have the log?
Original comment by jwsp...@gmail.com
on 30 Sep 2013 at 1:59
Hello all!
About two weeks ago I've checked out jswp clone (the last version which was on
google-code before migrating to github).
Especially thanks for full MultiSensor support, as now I use all sensors of my
AEON LABS 4-in-1 Multisensor.
And I want to say that the binding works very stable in general.
But I have the same problem as Der Rocka, with another device:
TKBHOME TZ66D (http://www.pepper1.net/zwavedb/device/341).
About an hour or two after I start the binding, it becomes dead. Status polling
(BinarySwitchGet) and sending commands (BinarySwitchSet) stop working. Even
incoming status reports (my controller is in "Tap right paddle twice" (#3)
association group) from the device do not reach the binding (or the controller,
I don't know). The device itself works definitely, because:
1) It sends commands to other associated devices, and they always react (for
example, I have another switch associated with "Tap right paddle once" (#2)
group, and it always switches on/off when I tap the right paddle once).
2) The diode indicating network activity flashes when I tap the right paddle
twice.
3) The device receives commands and reports statuses from/to OZWCP.
I will provide logs tomorrow, but it is a very strange problem.
I am waiting for three similar devices arriving me this Wednesday. The devices
are the dimmers:
- two TKBHOME TZ65D (http://www.pepper1.net/zwavedb/device/343);
- one TKBHOME TZ65S (http://www.pepper1.net/zwavedb/device/424).
So, I will install them and test, probably this weekend.
By the way, I also have a Fibaro Double Switch and it works perfectly, and
never was dead in my network.
Original comment by roher.ro...@gmail.com
on 30 Sep 2013 at 2:07
By the way, as now I have complete development environment setup, I have access
to the code. I've seen that "BasicSet" to the Controller is always treated as
"BasicReport". I want to implement so that it will be a default behaviour, but
if I put something like "5:1:command=basic_set" in the item configuration, this
item (for example, a Switch) will react only on "BasicSet", sent from the node
5:1 to the controller. I will explain why I need it:
The TKBHOME TZ66D (and other TZ.. I think) always sends "BasicSet" to the
devices associated with it.
As I've mentioned previously, my controller is in the "Tap right paddle twice"
group.
Assuming the problem from the previous post is solved (the device is not DEAD),
I double-click the right paddle of my switch. It doesn't change the load
connected to the switch (cause the left paddle is responsible for it), the
switch only sends "BasicSet" to the controller. I want, for, example, to
activate "Nobody at home" mode by this event, but now our binding treats it as
"BasicReport", and just sets the "Light_Hall", for example, to ON (or OFF).
But if I implement this command, and make a configuration like this:
Switch Light_Hall "Light in Hall" (Hall)
{zwave="5:1:command=switch_binary"}
Switch Nobody_At_Home "Nobody at Home" (Service)
{zwave="5:1:command=basic_set"},
after I double-click the right paddle of my switch, the "Nobody_At_Home" will
be set to ON (or OFF), depending on the value, and "Light_Hall" will not be
touched.
Do you support this idea?
Or maybe you have some counter-arguments, or maybe another proposal of
configuration string?
Let's discuss it ))
Original comment by roher.ro...@gmail.com
on 30 Sep 2013 at 3:46
It should already work that way. Normally you'd have to specifically add
respond_to_basic=true to a binding string to have it accept the basic command
class in addition to the one specified.
Your binding string should look like the strings below:
Switch Light_Hall "Light in Hall" (Hall)
{zwave="5:1:command=switch_binary"}
Switch Nobody_At_Home "Nobody at Home" (Service) {zwave="5:1:command=basic"}
Original comment by jwsp...@gmail.com
on 30 Sep 2013 at 4:54
make sure not to toggle Nobody_At_Home from the openhab interface though as
this would probably toggle the Light_Hall switch.
Original comment by jwsp...@gmail.com
on 30 Sep 2013 at 4:56
Thanks, I didn't think about it.
But in my case I can separate switch_binary and basic classes.
And what if the device doesn't support switch_binary class?
Then we obviously cannot do like this:
Switch Light_Hall "Light in Hall" (Hall) {zwave="5:1:command=basic"}
Switch Nobody_At_Home "Nobody at Home" (Service) {zwave="5:1:command=basic"}
because they will be identical from binding point of view.
But maybe you are right, and it's not worth spending time -- I cannot remember
any device that supports ONLY basic command class.
And about toggle - I may dislpay it as Text instead of Switch in the UI, and
nobody will be able to toggle it (except exlicit set from XMPP or OSGI Console).
Original comment by roher.ro...@gmail.com
on 30 Sep 2013 at 5:21
Unfortunately not JwS - sorry - if/when it happens again I will copy the log
across from my prod machine and send you a copy.
Original comment by ben.jone...@gmail.com
on 30 Sep 2013 at 7:12
Roher,
A device will either support multi instance / endpoint support or multiple
command classes on the same node for different functions on a node. The latest
version of the binding supports both. With the same command class on the same
node there is no way to differentiate anymore.
JwS
Original comment by jwsp...@gmail.com
on 30 Sep 2013 at 9:29
Yeap - that's exactly what I wanted to say, so there's no need for additional
implementation about this point.
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 5:10
Hmm... I've added a new device to my network, an everspring SF812 smoke sensor.
It made me realize that one of my assumptions (and of open-zwave) is incorrect:
I assumed that every non (frequently) listening device would automatically have
a wake-up class. Now it appears that this is not the case. This device never
wakes up. It only sends packets when an alarm is triggered or the battery is
almost empty.
What's even worse is that it supports configuration / adjustment only during
the first 15 minutes that it is included in the network. Then it simply isn't
reachable anymore until it is triggered.
Now after a restart of openHAB there is no way of communicating with it
anymore. So that means: No state info (not on the battery, nor on the state of
the sensor). To make sure that it still works as expected, the only way to get
it to do something is to hit the test button.
It will also stay in the initializing state forever after a restart.
I have to think a bit about how we are going to deal with these devices.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 8:29
Almost like you need the ability to manually define/initialise some nodes. Not
sure how that would work, but it could be incorporated into your idea of
persisting device configs?
Original comment by ben.jone...@gmail.com
on 1 Oct 2013 at 8:45
I was thinking along the same line indeed.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 9:09
Oh...what does Everspring say about it?
A choice could be to add a config-String that says that the item won't
communicate in a "normal" way. So that no communication is needed.
What steps are done during the initialization process? Could some be done as
generell configurations for those devices? Like no communication is good
communication for those devices?
Best,
André
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 9:09
I've more or less solved it I guess. Based on the protocol information (that
comes from the controller EEPROM) for the node, we already construct the
command classes based on the device class. It seems that my smoke sensor does
not support additional command classes on top of the mandatory by the device
class, or versions of command classes > 1.
This means that the node info is complete after the protocol information. No
need to query the device.
In addition to this I've added support to add a command class based on a
received message, in addition to the protocol info and the received Node
information frame. This way command classes that somehow are not (yet)
initialized based on the latter two, will be added based on a received message.
As I promised binaries (for 1.3.1), here they are, including this adjustment.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 10:08
Hello! As promised, sending the logs of my zwave binding (after today restart).
As you can see, node 7 (my TKBHOME switch) stays alive for about 20 minutes
after the start, and then becomes dead.
And could you please also look why my node 18 is marked as DEAD at
initialization stage? In general it works ok, the binding receives updates from
the device and changes the item's values, but the following items never change,
they always stay uninitialized (I think it is because node is initially marked
as DEAD):
Switch Multi_Sensor_Balcony_Dead "Multi Sensor Balcony Status"
(Balcony_DevInfo)
{zwave="18:1:command=info,item=dead,refresh_interval=600"}
String Multi_Sensor_Balcony_Update "Multi Sensor Balcony Update Time:
[%1$td.%1$tm.%1$tY %1$tT]" (Balcony_DevInfo)
{zwave="18:1:command=info,item=last_update,refresh_interval=600"}
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 10:44
Attachments:
Great! Are those binaries with the changes in the zwave binding string
(addition of "command=")?
The process you described getting the command classes of such an item sounds
good to me!
Thank you.
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 11:12
It seems that the multi sensor sends a listening flag... but it isn't. So we
get time-outs and eventually we report it dead, instead of using the wake-up
queue.
Is it powered or does it use batteries?
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 11:13
DerRocka, Yeah, it uses the new binding string format.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 11:14
OK, I've seen in the pepper DB that the next version of the multi-sensor will
correctly report the listening flag. So I guess I can add a workaround to the
binding to override it and set it to false.
Only thing I'm not sure about is how it behaves if it's connected to an USB
power source. When it stops sending wake-up intervals then, we have a problem
and then the listening bit should be dependent on the power situation (USB
powered versus battery powered).
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 11:26
so...testing right now :)
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 11:26
It can be both - either battery-powered or usb-powered. If usb-powered it is
listening.
The device should be excluded from the network and then re-included, if the
power is switched from batteries to usb and vica-versa.
In my configuration it is constantly powered from usb, so in term of z-wave it
is mains-powered, so we should not use the wake-up queue, as the device never
sleeps.
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 11:28
Oh, I've just answered your question without knowing it :)
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 11:29
Hi,
how is the syntax for all the info things.
Above you wrote:
String ZwaveStatsACK "Number of Acknowledgments [%s]" (gZwaveStats)
{zwave="1:command=info,item=ack"}
But I won't get ack,can,nodeid,homeid etc. all other seem to work just fine.
And I get the battery status of my Everspring siren (yeah... :) )
But the siren itself I can't test right now, because if I would turn it on I
can't hear it because of the ca. 25km distance to my home :-D
André
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 11:50
Or am I just to impatient? :)
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 11:53
DerRo, it was a mistype in the example.
I've also tried this, but it didn't work for me.
After that I've changed item type from String to Number, and everything works.
So, put 'Number ZWaveStatsACK bla-bla-bla...' in your item config file.
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 11:53
It used to be string types, but ben changed them to ints...
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 11:55
DerRocka, i've found it. I've implemented the decoding of
Sensor_Multilevel_Supported_GET incorrectly. I will fix this.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 11:56
oh...yes. So too impatient :)
should have made more thoughts about it. But it is easier to ask. So thanks and
sorry, becaus I read that recently again :)
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 12:00
Could it be possible to get to the highest range of int with some numbers in
error cases perhaps? So that an exception is thrown? Or couldn't it be?
If the first case (string) was casted from int it makes no difference though.
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 12:04
And the new binding with Sensor_Multilevel_Supported_GET fixed. Could you test
it DerRocka?
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 12:31
Sorry, I meant Roher... Also your node 7 seems to be a genuine routing problem.
It tries 3 times to send a message. Could you try moving it closer or adding a
node in between. You could also try the open-zwave control panel to assign
different return routes to the node (also see the discussion in 261 for some
tips)
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 12:36
hi,
I'll replace it anyway. Yes I tried it and battery status of the sirene seems
to work just fine. But I will try the sound this evening.
Right now I am testing different info strings for the nodeid, homeid, routing
etc. How are the zwave strings for those?
Changing the Strings to Numbers for the ACKs, CANs etc. works fine.
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 12:50
Emm, and these binaries are compatible with 1.4.0-SNAPHOT openhab? Because now
I am using that one, compiled from your clone.
About node 7 - I've also thought about the routing issue, but:
1) Why then does it work for 20-30 minutes everytime after I start the binding?
2) I already have two nodes between this node and the controller, and I also
have a node farther from the controller than this one, and it works without any
issues.
I've already tried to update neighbours list and assign return routes for all
my devices a week ago, but the situation didn't change.
Doesn't all this seem strange?
Maybe it's worth trying to exclude this node from my network and include it
again?
Original comment by roher.ro...@gmail.com
on 1 Oct 2013 at 1:07
btw. where can I find your github clone? And do I have to be logged in? Never
used it before. But perhaps some question (e.g. nodeid etc.) can be answered
throug a look at your code.
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 2:38
https://github.com/jspuij/openhab
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 3:02
No, 1.4.0 can be compiled from my clone, that's also up to date.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 3:03
Hi JwS,
unfortnately the Everspring siren can't be switched on with the following line
and the switch item in my sitemap:
Switch Alarm_Sirene "Alarm-Sirene" <siren-on> (gAlarmSystem) {
zwave="3:command=switch_binary" }
Any ideas? The battery info is working really well.
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 4:36
Could you provide the log. I have the same binding string and it works pretty
well. It can take up to 2 seconds to switch on though, because it's not always
listening.
Original comment by jwsp...@gmail.com
on 1 Oct 2013 at 5:18
Hi,
yes of course. Last 5000 lines with several restarts. The siren is Node 3.
how is your line for getting the homeid of your controller? The other devices
seem to work really well.
Thank you!
Original comment by DerRo...@gmail.com
on 1 Oct 2013 at 5:47
Attachments:
Original issue reported on code.google.com by
jwsp...@gmail.com
on 2 Sep 2013 at 12:45