Are you sure the battery is for the Z-Wave … Thermostats usually have power on them … If I were the designer I would get the power from the 24 volts used to control the HVAC system.
The batteries are typically used to maintain the time of day clocks so that your schedule does not get screwed up on power outages. When I did some low level programming on Z-Wave a while back I do not recall the thermostat ever being offline. The HSM100 was the only device I had at the time to worry about going off line. It’s also why it’s such a strange protocol. Once it sees a motion it wakes up the Z-Wave device sends a message and goes back to sleep for a minimal amount of time … and will not wake up even if it sees another motion. All to save battery power.
[quote=“RichardTSchaefer, post:21, topic:170311”]Are you sure the battery is for the Z-Wave … Thermostats usually have power on them … If I were the designer I would get the power from the 24 volts used to control the HVAC system.
The batteries are typically used to maintain the time of day clocks so that your schedule does not get screwed up on power outages. When I did some low level programming on Z-Wave a while back I do not recall the thermostat ever being offline. The HSM100 was the only device I had at the time to worry about going off line. It’s also why it’s such a strange protocol. Once it sees a motion it wakes up the Z-Wave device sends a message and goes back to sleep for a minimal amount of time … and will not wake up even if it sees another motion. All to save battery power.[/quote]
It would probably be useful to explain exactly what we mean by ‘a thermostat’. We are referring to a TRV (Thermostatic Radiator Valve). The normal method of central heating in the UK (and other parts of Europe) is to use a furnace to heat water that is pumped around the home. As the water passes around the home it goes into ‘radiators’ (large thin rectangular metal boxes on the wall) that become hot and heat the room. There is typically a TRV on each radiator that is used to control the amount of water (if any) that flows into the radiator which in turn regulates the amount of heat to the room. Normally these are mechanical devices that require no power, but in the case of the zWave enabled Danfoss Living Connect each of these thermostats uses a couple of AA batteries (it isn’t wired to anything else). The furnace normally has a completely separate switch which is connected to the kind of thermostat you would normally see connected to a HVAC and that is mains powered. The TRV is rather like having something that opens and closes individual AC vents based on the temperature of the room.
highly interesting…
it could also be that the vera “uses” the TRV more then the danfoss system itself i.e. make more valve movements
i think the problem with this all is in the way vera polls the devices in a timely matter and in between listens to incomming traffic from the devices… somewhere along the line it gets collisions… they sorta look the same as with the old ibm network standard where too much traffic at once tends to make the system mix up things and drops packets . i.e. collisions
@mtf,
I realize it’s been quite some time since you worked on this. Any chance you’d be willing to release your z-wave “shim” in it’s current state? I’ve got a problem with Vera ignoring some Z-Wave messages that I’d like to use to trigger Luup actions, and would be trivial to fix if I could “sniff” raw Z-wave traffic.
Hugh
Well, looks like a quiet thread. 
So as I’m still trying to avoid writing (or even compiling) any native code for MiOS, I decided to go with a “low tech” approach.
I installed socat from the openwrt repo. As it handles serial ports, I got good results using the following commands to send a copy of all the raw Z-Wave traffic to TCP port 8888:
socat -v -x pty,raw,echo=0,link=/dev/zwave_redirect /dev/ttyS0,raw,b115200,echo=0 2>&1 | socat -u - udp-send:localhost:8888&
socat -u udp-recv:8888 tcp-l:8888,fork&Connecting to TCP port 8888 shows the following fairly parsable output:
nc localhost 8888
< 2012/05/17 16:24:16.191050 length=12 from=686 to=697
06 01 09 01 41 c9 0c 00 04 10 01 66 ....A......f
--
> 2012/05/17 16:24:16.210686 length=1 from=365 to=365
06 .
--
> 2012/05/17 16:24:16.221017 length=6 from=366 to=371
01 04 00 41 38 82 ...A8.
--
< 2012/05/17 16:24:16.231147 length=12 from=698 to=709
06 01 09 01 41 c9 0c 00 04 10 01 66 ....A......f
--
> 2012/05/17 16:24:16.260679 length=7 from=372 to=378
06 01 04 00 41 39 83 ....A9.
--
< 2012/05/17 16:24:16.271735 length=12 from=710 to=721
06 01 09 01 41 c9 0c 00 04 11 01 67 ....A......g
--
> 2012/05/17 16:24:16.315765 length=1 from=379 to=379
06 .
--So, I guess that’s step 1: intercept the traffic. Step 2 would be to write a plugin to connect to the TCP port and parse the output and generate Luup events in some meaningful way.
Anyone feel inspired to write the plugin?
Wow, this looks like it died a year ago. Too bad (sorry for reviving a dead thread).
I was hoping to see how this project was coming along.