Sending and Receiving Low Level z-Wave Messages

Developer's Corner General Dev Discussions
#1

I have already asked this question elsewhere on another thread, but I thought it deserved to be asked in a more visible way.

I know that it is possible to send low level z-Wave commands using SendData, but as yet nobody has been able to let me know how you can listen to the low level z-Wave messages that are sent by a device. [People following other threads will know that I am extremely unhappy with the quality of support in the Vera for the Danfoss Living Connect thermostats and I don’t think I am alone in this view]

That is the question that has been posted elsewhere, but from here onwards is a completely new thought.

If there is no way to get this low level information through MiOS I propose the answer is as follows:

To develop a low level daemon in C that connects directly to /dev/tts/1 (the z-Wave controller).

To have that daemon create two pseudo tty devices.

The first pseudo tty can be used by MiOS to send and receive messages to the z-Wave controller by setting that pseudo tty as the port in the z-Wave device configuration.

The second pseudo tty can be used by anything that wants to communicate directly with z-Wave devices. My theory is that the z-Wave protocol should be simple enough to screen out the messages that a third party is interested in and we should even be able to hide those messages from MiOS.

I also propose that the daemon should be able to open a port on the Vera that we can connect to if we want to listen to all z-Wave messages going back and forth. I know you can already do this using the logs, but this would be much better in my view and we could perhaps even produce something based on the open-zWave implementation that would then tell us the meaning of all the messages it sees. This would be an excellent diagnostic tool when we aren’t quite sure what is going on!

Does anybody see a major issue with this proposal or some reason why any of this would definitely not work?

If it does work we should be able to develop our own replacements for any poor implementation by MiCasaVerde.

#2

I note that not many people have read this posting and that nobody has posted a reply, but I have pushed on regardless.

I now have a daemon written in C that runs on the Vera and is able to connect to the z-Wave controller and open a pseudo tty that Vera talks to. The daemon passes data back and forth between the Vera and the z-Wave controller and both appear to be perfectly happy with the arrangement.

I have been able to dump the messages between the Vera and the z-Wave device directly to the screen and there was nothing too surprising in there.

I need to tidy the code up and then I will start to write something to parse the messages that are going back and forth with the eventual aim of manipulating the Danfoss Living Connect thermostats directly.

I am more than happy to receive input from anybody who has any thoughts on this project.

#3

Another update on progress.

I spent last night cleaning up the code and I now have a daemon that is permanently running and sitting between MiOS and the z-Wave controller. From what I can see it is working flawlessly.

I have also added a port I can telnet to which shows me all the chatter between MiOS and the z-Wave controller. I find that relatively useful because it updates instantly (unlike the buffered log files) and I can connect very quickly and easily at any time without needing to enable verbose logging.

I am starting to rethink my original idea. I no longer think that I want a second pseudo tty for something other than MiOS to connect to. I think it would be better to open up a tcp/ip port that can be used for multiple connections.

#4

Glad you are making progress. Do you have access to the commands that Danfoss uses to communicate to the tstat? My understanding is that the thermostat does not use standard zwave commands for some of its functions.

  • Garrett
#5

MiOS relies on the optional Z-Wave callback id in order to match the response with the request and AFAIK the callback id is generated by MiOS …

#6

I haven’t got to the stage of taking apart the z-Wave commands that are flowing back and forth so I can’t really comment very much on them as yet because I don’t entirely understand the zWave protocol.

My main observations so far are:

There are some very substantial delays in terms of data being sent by MiOS to the thermostats. MiOS does not seem to have any concept of saying, this is a battery powered device and I just heard from it so now would be a great time to try sending a message to it because it is probably awake. Instead MiOS appears to sit around and can wait quite a long time before trying to send a message again at which point it is too late. I had always suspected this to be the case, but now I have been able to verify for myself that this is exactly what happens. Incidentally this even happens when the zWave network is silent.

I also note that the ‘Got CAN’ message is generated by situations where both MiOS and the controller try to send a message at a similar sort of time. While MiOS appears to respond correctly to the message it has received with a 0x06 the zWave controller doesn’t and throws a 0x18.

For example (V is Vera, Z is the controller)

Z 10:12:23.190 0x01 0x08 00 0x04 00 0x34 0x02 0x84 0x07 0x46
V 10:12:23.196 0x01 0x10 00 0x19 0x34 0x05 0x43 0x01 0x01 0x01 0x0a 0x05 00 00 00 00 0x7e 0xf4
Z 10:12:23.200 0x18
V 10:12:23.231 0x06

This is interesting and I could reduce how often this happens by simply swapping the order of the Vera messages to the zWave controller because I know that the z-Wave controller has sent a message. I could put the MiOS command in a buffer and wait for a 0x06 from MiOS first and then pass them together. This won’t work all the time because sometimes it happens the other way round, but it will help. Whether I really want to slow down the delivery of messages by trying to swap the order I don’t really know, but on the other hand if I don’t do this then MiOS simply decides to delay all messages for another second anyway on the basis that the z-Wave dongle is in a funny state, so it may be worthwhile waiting a fraction of a second to see if the 0x06 arrives. MiCasaVerde if you are listening why not do this as standard? It takes a negligible amount of time to run a select() on the file descriptor to see if the zWave device has sent you something and if it has you could simply read what it has to say and respond to that first (if necessary) and hold your message momentarily.

Got CAN? How to fix this?
#7

This has been fixed in the latest beta firmware.
http://wiki.micasaverde.com/index.php/Release_Notes

#8

This has been fixed in the latest beta firmware.
http://wiki.micasaverde.com/index.php/Release_Notes

MCVFlorin,

This is still not working for 3-in-1 sensors like the HSM-100. A few of us have stated this in the beta form for the current beta build.

  • Garrett
#9

[quote=“mcvflorin, post:7, topic:170311”]This has been fixed in the latest beta firmware.
http://wiki.micasaverde.com/index.php/Release_Notes

Is polling a battery operated node the same as sending commands to the battery operated node, for example the command to change the heat point? If it isn’t then polling the node isn’t going to help a lot and I get the impression that normally polling means checking the status of a device.

Also I note that a number of my devices rarely seem to rarely update LastWakeup although the device is awake enough to send frequent battery level information so I am not sure the whole wakeup process is working properly anyway. I also have concerns that the Vera likes to send all outgoing messages in a pre-determined order with no sense of priority. Has this been addressed as well? Otherwise the poll might not reach the battery powered device anyway.

Strangely enough I have never experienced problems with 3-in-1 sensors updating temperature/light until recently when I have become less and less convinced that they are updating all that well.

I haven’t experienced UI5 at all as yet. For some reason I have felt a little reluctant to upgrade to a UI I might not recognise. In general I don’t have any problem with UI4 other than the fact that my thermostats are very poorly supported.

#10
MiOS does not seem to have any concept of saying, this is a battery powered device and I just heard from it so now would be a great time to try sending a message to it because it is probably awake.

Not true. This is the ONLY way that battery-operated devices work. Otherwise nobody would get any battery operated devices to work.

Regarding the new change in the last release, we have ALWAYS sent queued commands when a battery device wakes up. Originally we also polled the device (ie asked for it’s current state) but stopped because users complained it drained the batteries. But to get the HSM100 to show status, we added this back again, this time making it user-configurable so you can poll only the devices you want.

For me the HSM-100 is working fine. I’ll need to get a tech support code from a user who is having problems. Please email a code to aaron at mios dot com and I’ll see why it’s not working for you.

#11

[quote=“micasaverde, post:10, topic:170311”]

MiOS does not seem to have any concept of saying, this is a battery powered device and I just heard from it so now would be a great time to try sending a message to it because it is probably awake.

Not true. This is the ONLY way that battery-operated devices work. Otherwise nobody would get any battery operated devices to work.

Regarding the new change in the last release, we have ALWAYS sent queued commands when a battery device wakes up.[/quote]

It is really the thermostats that are the major problem for me rather than the HSM100. Here is an example I have a thermostat that is device_id 93 and node 43 (0x2b). I know the device is about to wake up in the next few seconds, so here are some bits of your logs:

08 02/06/12 9:21:02.013 JobHandler_LuaUPnP::HandleActionRequest device: 93 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat action: SetCurrentSetpoint <0x402>
08 02/06/12 9:21:02.013 JobHandler_LuaUPnP::HandleActionRequest argument NewCurrentSetpoint=10 <0x402>
06 02/06/12 9:21:02.014 Device_Variable::m_szValue_set device: 93 service: urn:upnp-org:serviceId:TemperatureSetpoint1_Heat variable: SetpointTarget was: 13 now: 10 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:0 <0x402>
02 02/06/12 9:21:02.016 ZWJob_SendData UPDATE MANUAL ROUTE 43=(nil) <0x402>
06 02/06/12 9:21:09.984 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328519772 now: 1328520069 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:0 <0x803>
06 02/06/12 9:21:09.987 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.033 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328520069 now: 1328520070 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:0 <0x803>
06 02/06/12 9:21:10.036 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.083 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328520070 now: 1328520070 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.084 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.163 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328520070 now: 1328520070 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.164 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.213 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328520070 now: 1328520070 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.214 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.263 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryDate was: 1328520070 now: 1328520070 #hooks: 1 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>
06 02/06/12 9:21:10.264 Device_Variable::m_szValue_set device: 93 service: urn:micasaverde-com:serviceId:HaDevice1 variable: BatteryLevel was: 60 now: 60 #hooks: 0 upnp: 0 v:(nil)/NONE duplicate:1 <0x803>

The log file continues, but we never see a LastWakeup change for this device, although quite honestly it must clearly be awake to some extent because it is sending us battery updates. Looking at the z-Wave messages we see the following (these are the first messages after 09:21:00 so the Setpoint change has yet to generate any traffic at all)

Z 09:21:09.980 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:09.982 0x06
Z 09:21:10.000 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:10.031 0x06
Z 09:21:10.040 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:10.081 0x06
Z 09:21:10.110 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:10.161 0x06
Z 09:21:10.170 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:10.211 0x06
Z 09:21:10.220 0x01 0x09 00 0x04 00 0x2b 0x03 0x80 0x03 0x3c 0x65 [battery status info as in logs]
V 09:21:10.261 0x06
V 09:21:14.582 0x01 0x03 00 0x16 0xea
Z 09:21:14.590 0x06
Z 09:21:14.890 0x01 0x05 00 0x19 0x85 0x01 0x67
V 09:21:14.891 0x06
V 09:21:16.660 0x01 0x10 00 0x19 0x2b 0x05 0x43 0x01 0x01 0x01 0x0a 0x05 00 00 00 00 0x86 0x13 [hooray MiOS is talking to my device, 6 seconds after the battery info, rather too late in the day I suspect]
Z 09:21:16.670 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:21:16.711 0x06
Z 09:21:19.290 0x01 0x09 00 0x04 00 0x12 0x03 0x80 0x03 0x35 0x55
V 09:21:19.341 0x06
Z 09:21:19.350 0x01 0x0c 00 0x04 00 0x12 0x06 0x43 0x03 0x01 0x42 0x03 0xe8 0x0b
V 09:21:19.391 0x06
Z 09:21:19.400 0x01 0x0a 00 0x04 00 0x12 0x04 0x46 0x08 00 0x7f 0xd6
V 09:21:19.441 0x06
V 09:21:27.723 0x01 0x03 00 0x16 0xea
Z 09:21:27.730 0x06
Z 09:21:28.170 0x01 0x05 00 0x19 0x86 0x01 0x64
V 09:21:28.172 0x06
V 09:21:29.748 0x01 0x10 00 0x19 0x2b 0x05 0x43 0x01 0x01 0x01 0x0a 0x25 00 00 00 00 0x87 0x32 [MiOS tries again, but it must be asleep by now!]
Z 09:21:29.760 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:21:29.781 0x06
Z 09:21:35.980 0x01 0x09 00 0x04 00 0x17 0x03 0x80 0x03 0x31 0x54 [here comes a different thermostat, battery report]
V 09:21:35.982 0x06
Z 09:21:36.000 0x01 0x0c 00 0x04 00 0x17 0x06 0x43 0x03 0x01 0x42 0x03 0xe8 0x0e [setpoint reporting]
V 09:21:36.031 0x06
Z 09:21:36.060 0x01 0x0a 00 0x04 00 0x17 0x04 0x46 0x08 00 0x7f 0xd3 [control schedule override report]
V 09:21:36.081 0x06
Z 09:21:36.090 0x01 0x08 00 0x04 00 0x17 0x02 0x81 0x05 0x62 [clock request]
V 09:21:36.131 0x06
V 09:21:40.141 0x01 0x03 00 0x16 0xea
Z 09:21:40.150 0x06
Z 09:21:40.440 0x01 0x05 00 0x19 0x87 0x01 0x65
V 09:21:40.461 0x06
V 09:21:42.201 0x01 0x0f 00 0x19 0x17 0x04 0x81 0x06 0x29 0x15 0x05 00 00 00 00 0x88 0xcc [hooray MiOS responds 6 seconds later again to tell the thermostat the time]
Z 09:21:42.210 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:21:42.242 0x06
Z 09:21:42.370 0x01 0x05 00 0x19 0x88 0x01 0x6a
V 09:21:42.372 0x06
V 09:21:42.381 0x01 0x0f 00 0x19 0x17 0x04 0x81 0x06 0x29 0x15 0x25 00 00 00 00 0x89 0xed [sorry MiOS you really won’t get through now]
Z 09:21:42.390 0x06 0x01 0x04 0x01 0x19 0x01 0xe2

Now this is a more interesting log because this is a device that does show a change in LastWakeup

Z 09:23:54.970 0x01 0x09 00 0x04 00 0x36 0x03 0x80 0x03 0x3c 0x78 [another battery report]
V 09:23:54.972 0x06
Z 09:23:54.990 0x01 0x0c 00 0x04 00 0x36 0x06 0x43 0x03 0x01 0x42 0x03 0xe8 0x2f [setpoint report]
V 09:23:55.035 0x06
V 09:23:55.036 0x01 0x11 00 0x19 0x31 0x06 0x60 0x0d 0x01 0x01 0x25 0x02 0x05 00 00 00 00 0x95 0x1a [different device]
Z 09:23:55.040 0x01 0x0a 00 0x04 00 0x36 0x04 0x46 0x08 00 0x7f 0xf2 0x18 [climate control schedule]
V 09:23:55.071 0x06
Z 09:23:55.080 0x01 0x08 00 0x04 00 0x36 0x02 0x81 0x05 0x43 [clock request]
V 09:23:55.121 0x06
V 09:23:56.080 0x01 0x11 00 0x19 0x31 0x06 0x60 0x0d 0x01 0x01 0x25 0x02 0x05 00 00 00 00 0x95 0x1a [different device]
Z 09:23:56.090 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:23:56.096 0x01 0x03 00 0x16 0xea
Z 09:23:56.100 0x18 [Got a CAN]
V 09:23:56.112 0x06
Z 09:23:56.120 0x01 0x05 00 0x19 0x95 00 0x76
V 09:23:56.121 0x01 0x03 00 0x16 0xea
Z 09:23:56.130 0x18 [Got a CAN]
V 09:23:56.151 0x06
Z 09:23:56.160 0x01 0x0d 00 0x04 00 0x31 0x07 0x60 0x0d 0x01 0x01 0x25 0x03 00 0x8b [different device]
V 09:23:56.191 0x06
V 09:23:58.160 0x01 0x0f 00 0x19 0x36 0x04 0x81 0x06 0x29 0x17 0x05 00 00 00 00 0x96 0xf1 [hooray MiOS got there in 3-4 seconds with clock info so the device is still awake!]
Z 09:23:58.171 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:23:58.211 0x06
Z 09:23:58.220 0x01 0x05 00 0x19 0x96 00 0x75
V 09:23:58.261 0x06
Z 09:23:58.270 0x01 0x08 00 0x04 00 0x36 0x02 0x84 0x07 0x44 [device responds - this appears to update LastWakeup]
V 09:23:58.311 0x06
V 09:23:58.323 0x01 0x0d 00 0x19 0x36 0x02 0x46 0x07 0x05 00 00 00 00 0x97 0x0c [climate control message]
Z 09:23:58.330 0x06 0x01 0x04 0x01 0x19 0x01 0xe2
V 09:23:58.361 0x06
Z 09:23:58.370 0x01 0x05 00 0x19 0x97 00 0x74
V 09:23:58.411 0x06
Z 09:23:58.420 0x01 0x0a 00 0x04 00 0x36 0x04 0x46 0x08 00 0x7f 0xf2
V 09:23:58.461 0x06
V 09:23:58.474 0x01 0x0d 00 0x19 0x36 0x02 0x84 0x08 0x05 00 00 00 00 0x98 0xce

Now with the best will in the world waiting 3-4 seconds to respond to a battery powered device isn’t a great performance. MiOS clearly isn’t rushing to respond to battery powered devices.

Looking at these logs it is of little surprise to me that my devices aren’t working very well and the batteries are running flat very quickly. Ideally all messages to a battery powered device would be sent within a fraction of a second of any messages being received from the device and the same would be true of any responses to requests for information. If this happened I could also send a message to the device to tell it to go back to sleep as suggested by Danfoss.

Looking at the logs my radiator thermostats must stay awake for around 5 seconds every time they communicate with MiOS, whereas in the ideal world they would receive my messages and then be sent a command to go back to sleep. This appears to explain why Danfoss say batteries in their thermostats last a couple of years whilst with MiOS they last a couple of months.

#12

Following on from my last post I really just wanted to say that I am a fan of the Vera, I own 4 of them. I do want to use it and my objective is not to tear MiOS to pieces, but there clearly is a substantial problem in this area. Most users won’t delve so deeply into what is happening they will just return the devices on the basis that they don’t work. This is bad for MiCasaVerde and Danfoss who both get the blame for these problems and unfortunately I must say it appears that the main fault I am seeing with the radiator thermostats is in MiOS.

#13

I take back part of my earlier comment about the Vera not doing anything to tell the thermostat to go back to sleep. It does send that message to put the thermostat to sleep, in the event that things are going well. As shown at the bottom of the log I posted, but this is a really good reason to make sure you send your commands early and don’t wait for a wakeup because Vera will close that connection!

#14

Just a brief update on progress, so that people know this project hasn’t been abandoned.

I haven’t started to inject any of my own zWave commands just yet, but my code now recognises the general structure of zWave messages and is able to store them in a structure to make processing them somewhat simpler. I expect to start the more serious business of manipulating zWave messages in the next couple of days.

My current thinking is the best way to proceed is to manipulate the zWave messages in such a way that the presence of the daemon is hidden from MiOS completely, but to ensure that anything I perceive to be a bug in MiOS is fixed, whilst enhancing battery life very substantially.

#15

Just out of curiosity: Are you going to support synthetic Z-Wave commands via [tt]SendData[/tt] that get mapped to real Z-Wave commands by your interceptor - or are you going another route to inject arbitrary Z-Wave commands and to be able to use the Z-Wave callback ID mechanism to match the requests with the responses?

And don’t forget to support arbitrary Home IDs. :slight_smile:

#16

I am open to suggestions on this. I was originally thinking of providing an entirely separate tcp/ip socket and doing everything through through Lua/Luup talking to that, but then I started to think it might be easier to just fix problems I perceive with the zWave messages sent by MiOS to make the whole thing transparent to the end user, but that wouldn’t help you get the callback information. Really there is no reason why I can’t just do both and I think that will be the best approach.

I am currently looking into the callback ID stuff. My intention is to track the callback ID being used by MiOS. I note that MiOS uses callback ID’s in sequential order, consequently if our injected messages add have a callback ID that is at least 128 greater than the current MiOS callback ID the two are unlikely to ever clash. For example if MiOS is currently using 0x05 I would offer at least 0x85. There is the question of how to communicate a suggested callback ID with Lua/Luup.

I also need to match the ACK/NAK/CAN so that I know who should get the ACK/NAK/CAN for a message that has been sent, but I think I have that in hand already.

I still don’t fully understanding the 0x19 messages, in particular the first 5 of the last 7 bytes which I assume relate to routing, but on the other hand I probably don’t need to understand it. My thinking is that I should be able to just record the bytes that MiOS thinks should be used and use them for my own messages.

There is also the question of which version of zWave somebody is using because 3.20 and 2.78 appear to work in slightly different ways.

Feel free to let me know how it can be done and I am sure it can be thrown in :slight_smile:

#17
I note that MiOS uses callback ID's in sequential order, consequently if our injected messages add have a callback ID that is at least 128 greater than the current MiOS callback ID the two are unlikely to ever clash.

I wouldn’t be sure without testing - did you check the callback ID frequency while LuaUPnP (or Vera) is starting up or executing complex scenes?

Sending a complete Z-Wave setback schedule to 10 thermostats will generate at least 70 callback IDs (one Z-Wave command per day of week) - well, the example is somewhat constructed insofar as not all thermostats will wake up at the same time …

There is the question of how to communicate a suggested callback ID with Lua/Luup.

Why communicating the callback ID to the user? The user is interested in getting the response(s) for the command just sent and might even know nothing about the concept of ‘callback ID’.

Just an idea:
Write a Luup plugin that overloads (if possible and if using synthetic Z-Wave commands, otherwise define a new UPnP action for sending Z-Wave data) the [tt]SendData[/tt] action, add an UPnP state variable ‘CallbackHandler’ whose content gets called as a Lua function with the response data. The problem might be, that your interceptor doesn’t have access to the Lua space the Luup plugin and the callback handler is running in. So we would be back at socket communication …

Maybe guessed could chime in and suggest a (more) elegant solution to the problem?

There is also the question of which version of zWave somebody is using because 3.20 and 2.78 appear to work in slightly different ways.

IIRC, the Z-Wave version is stored in the filesystem. Of course, your interceptor should support both versions. :slight_smile:

#18

[quote=“Ap15e, post:17, topic:170311”]

I note that MiOS uses callback ID’s in sequential order, consequently if our injected messages add have a callback ID that is at least 128 greater than the current MiOS callback ID the two are unlikely to ever clash.

I wouldn’t be sure without testing - did you check the callback ID frequency while LuaUPnP (or Vera) is starting up or executing complex scenes?[/quote]

Looking through all the messages that ever seem to go back and forth it is pretty easy to spot that they are sequential and start up is a very good example of it.

Sending a complete Z-Wave setback schedule to 10 thermostats will generate at least 70 callback IDs (one Z-Wave command per day of week) - well, the example is somewhat constructed insofar as not all thermostats will wake up at the same time ...

I see your point. I hadn’t considered such heavy use of the zWave network.

There is the question of how to communicate a suggested callback ID with Lua/Luup.

Why communicating the callback ID to the user? The user is interested in getting the response(s) for the command just sent and might even know nothing about the concept of ‘callback ID’.

I think it would be useful to allow the person sending the zWave commands to be able to use a callback ID if they are doing something particularly complex. It has now struck me that I could simply maintain a mapping table. You could use a callback ID of your own choosing (if you needed a callback ID at all), safe in the knowledge that I would simply change it to something that didn’t clash with MiOS before passing it to the controller and then I could change it back to what you expected when I received the response, this is broadly similar to nat on a tcp/ip network. There is of course an argument that I could do exactly the same thing to MiOS, but I am not sure I should be so bold without a complete understanding of the zWave protocol.

Just an idea: Write a Luup plugin that overloads (if possible [b]and[/b] if using synthetic Z-Wave commands, otherwise define a new UPnP action for sending Z-Wave data) the [tt]SendData[/tt] action, add an UPnP state variable 'CallbackHandler' whose content gets called as a Lua function with the response data. The problem might be, that your interceptor doesn't have access to the Lua space the Luup plugin and the callback handler is running in. So we would be back at socket communication ...

Maybe guessed could chime in and suggest a (more) elegant solution to the problem?

I think socket communication may be a necessary evil, but I would imagine we should be able to wrap that socket communication up to make it nicer for the individual.

There is also the question of which version of zWave somebody is using because 3.20 and 2.78 appear to work in slightly different ways.

IIRC, the Z-Wave version is stored in the filesystem. Of course, your interceptor should support both versions. :slight_smile:

Ideally I agree and thanks for the hint that I might be able to get the info directly from the filesystem. I can probably also guess quite accurately from the format of the commands that MiOS is sending, because I think the 0x19 stuff is only used by 3.20. Another option is to perhaps just ask the z-Wave controller which version it is using, or watch the answer given to MiOS when it starts up.

#19
I think it would be useful to allow the person sending the zWave commands to be able to use a callback ID if they are doing something particularly complex.

You are correct - and being able to use a callback ID would reduce the number of simultaneous socket connection to 1.

Ideally I agree and thanks for the hint that I might be able to get the info directly from the filesystem.

For Vera V1 and V2:

root@HomeControl:/etc/cmh# cat zwave_version
#20

BTW, the frame format (including the Home ID) is specified on p. 9 in [tt]http://www.eilhk.com/en/product/Datasheet/Zensys/SDS10243-2%20-%20Z-Wave%20Protocol%20Overview.pdf[/tt].