Hi,
I have a HRT4-ZW thermostat which seems to be working all ok except that it doesn't seem to respond to GET 'setpoint' or SET 'setpointheating' commands. All other commands seem ok. Fhem responds ok when the changes are made at the thermostat unit.
I also get a couple of UNPARSED readings as so:
2015-08-06_17:15:13 hall_thermostat wakeup: notification
2015-08-06_17:20:12 hall_thermostat UNPARSED: THERMOSTAT_MODE 03400101
2015-08-06_17:20:12 hall_thermostat UNPARSED: THERMOSTAT_MODE 03400101
2015-08-06_17:20:12 hall_thermostat UNPARSED: SWITCH_BINARY 032501ff
2015-08-06_17:20:12 hall_thermostat UNPARSED: SWITCH_BINARY 032501ff
2015-08-06_17:21:13 hall_thermostat wakeup: notification
2015-08-06_17:21:13 hall_thermostat UNPARSED: THERMOSTAT_MODE 03400100
2015-08-06_17:21:13 hall_thermostat UNPARSED: THERMOSTAT_MODE 03400100
2015-08-06_17:21:13 hall_thermostat UNPARSED: SWITCH_BINARY 03250100
2015-08-06_17:21:13 hall_thermostat UNPARSED: SWITCH_BINARY 03250100
2015-08-06_17:25:13 hall_thermostat wakeup: notification
I get them showing up twice in the log file. The last two digits change when the thermostat switches on/off
Any ideas?
My mistake. It is responding to the SET setpointTemp but it doesn't update in fhem. It doesn't seem to respond to GET setpointTemp but will update ok report when changed at the dial....strange
Hi,
could you please make a "list" of that device? (Should be 'list hall_thermostat'')?
It looks like you are somehow missing the classes for SWITCH_BINARY and THERMOSTAT_MODE...
Regards,
Andreas.
The device is sending set on/off instead of report on/off, and FHEM was not able to interpret these messages, only to send them. I've added the setOn/setOff/setTmOff/etc messages to the parser.
This is an interim solution, the final one should be able to automatically parse arbitrary set/get messages.
Hello Rudi, hello cmillsy,
Zitat von: rudolfkoenig am 08 August 2015, 14:13:24
The device is sending set on/off instead of report on/off, and FHEM was not able to interpret these messages, only to send them. I've added the setOn/setOff/setTmOff/etc messages to the parser.
This is an interim solution, the final one should be able to automatically parse arbitrary set/get messages.
uups, I overlooked completely that it was a SET command instead of a GET...
I just had a look at the dokument at pepper for that device and it seems to me that this is really meant to be a SET command (to controll e.g. a boiler).
http://www.pepper1.net/zwavedb/uploads/resources/807598f86037c2d107cda7af87a55c2670d8e3bb.pdf
So I am not sure if it is a good way to just treat this SET as if it was a REPORT. The device should be able to respond to a GET with a correct REPORT if the class ist correctly implemented, but the device seems to be from around 2011, so it might that this on was not tested for full compatibility.
There are associations groups available, and i guess that the controller was associated with group 1 and group 2, thous receiving the set commands...
Association Command Class
(V1)
The following association groups are supported in the grouping identifier range 1– 5 respectively:
Group 1- Nodes controlled by Thermostat Mode SET command.
Group 2- Nodes controlled by Binary Switch SET command.
Group 3- Nodes to receive unsolicited Battery Level Reports or Low Battery Warnings.
Group 4- Nodes to receive Thermostat Set Point Reports.
Group 5- Nodes to receive unsolicited Multilevel Sensor Reports.
Each group contains a maximum of 4 nodes.Regards,
Andreas.
Hi, Thanks for the replies,
Yes, i have the controller associated to all the groups and the boiler receiver node associated to group 1 which switches ok. I've noticed the this receiver doesn't seem to send out reports when it's switched but will respond to GET swbstatus. I could poll this switched but then i noticed the unparsed message from the thermostat which does change on switching which is essentially the same status. The temperature and battery reports from the thermostat seem to be very few and far between and there doesn't seem to be any config value to increase the frequency so i have to poll these values.
Here's the 'list' of both thermostat and receiver
thermostat:
Internals:
DEF XXXXXXX 3
IODev ZWDongle_1
LASTInputDev ZWDongle_1
MSGCNT 6
NAME hall_thermostat
NR 99
STATE 20.0 C heating
TYPE ZWave
ZWDongle_1_MSGCNT 6
ZWDongle_1_RAWMSG 00040003028407
ZWDongle_1_TIME 2015-08-10 11:20:31
homeId XXXXXXXX
id 03
lastMsgTimestamp 1439202031
Readings:
2015-07-31 18:29:22 CMD ZW_APPLICATION_UPDATE
2015-08-10 10:44:09 UNPARSED SWITCH_BINARY 03250100
2015-08-06 15:10:13 assocGroup_01 Max 04 Nodes 0107
2015-08-06 15:20:13 assocGroup_02 Max 04 Nodes 01
2015-08-06 15:20:13 assocGroup_03 Max 04 Nodes 01
2015-08-06 15:25:13 assocGroup_04 Max 04 Nodes 01
2015-08-06 15:25:13 assocGroup_05 Max 04 Nodes 01
2015-08-09 14:05:27 battery 91 %
2015-08-06 15:35:13 config_1 255
2015-08-10 00:17:15 setpointTemp 20.0 C heating
2015-08-09 23:58:34 state TRANSMIT_NO_ACK
2015-08-09 05:50:46 temperature 23.0 C
2015-08-10 11:00:31 transmit OK
2015-08-10 11:20:31 wakeup notification
2015-08-06 17:40:13 wakeupReport interval 300 target 1
WakeUp:
13030543010101182503
Attributes:
IODev ZWDongle_1
classes MANUFACTURER_SPECIFIC VERSION BATTERY WAKE_UP SENSOR_MULTILEVEL THERMOSTAT_SETPOINT ASSOCIATION CONFIGURATION MARK THERMOSTAT_MODE SWITCH_BINARY
group heating
room ZWave,house
stateFormat setpointTemp
verbose 5
webCmd setpointHeating
widgetOverride setpointHeating:slider,15,1,25
reciever
Internals:
DEF XXXXXXXX 7
IODev ZWDongle_1
NAME boiler
NR 97
STATE off
TYPE ZWave
homeId XXXXXXXXX
id 07
Readings:
2015-08-07 10:24:52 reportedState off
2015-08-07 10:24:52 state off
2015-08-07 10:24:52 transmit OK
Attributes:
IODev ZWDongle_1
classes MANUFACTURER_SPECIFIC VERSION THERMOSTAT_MODE SWITCH_BINARY
event-on-change-reading state
group heating
room ZWave,house
stateFormat reportedState
verbose 0
Since creating those list's i've now updated and the unparsed messages are reported ok. Thankyou for that. As for the setpoint, if the unit simply does not report it's status i guess i could use a dummy to send the command and stay updated to the same value as he unit.
I'm still not getting any response from GET setpoints and the manual says it should do so i thought i'd post some logs to see if anybody can shed any light. It reports the setpoint fine if i change it at the dial but not from a GET setpoint. I have used a dummy to 'follow' the setpoint but i'd rather have it done properly if i can.
The z-wave information is here
http://www.horstmann.co.uk/files/3914/0231/8355/HRT4-ZW_Manual_Z-Wave_Information.pdf (http://www.horstmann.co.uk/files/3914/0231/8355/HRT4-ZW_Manual_Z-Wave_Information.pdf)
2015.10.20 13:17:40 2: ZWave get hall_thermostat setpoint
2015.10.20 13:17:40 3: getHallTemp: Scheduled for sending after WAKEUP
2015.10.20 13:22:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004080303400101
2015.10.20 13:22:01 5: SW: 06
2015.10.20 13:22:01 5: ZWDongle_1 dispatch 0004080303400101
2015.10.20 13:22:01 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03400101
2015.10.20 13:22:01 2: ZWave get boiler swbStatus
2015.10.20 13:22:01 5: ZWDongle_Write 00 13070225022507
2015.10.20 13:22:01 5: SW: 01090013070225022507e5
2015.10.20 13:22:01 4: ZWDongle_ReadAnswer arg:swbStatus regexp:^00040007..25
2015.10.20 13:22:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 0004000303400101
2015.10.20 13:22:01 5: SW: 06
2015.10.20 13:22:01 5: ZWDongle_1 dispatch 0004000303400101
2015.10.20 13:22:01 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:03400101
2015.10.20 13:22:01 4: ZWDongle_Read ZWDongle_1: CAN received
2015.10.20 13:22:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040803032501ff
2015.10.20 13:22:01 5: SW: 06
2015.10.20 13:22:01 5: ZWDongle_1 dispatch 00040803032501ff
2015.10.20 13:22:01 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:032501ff
2015.10.20 13:22:01 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040003032501ff
2015.10.20 13:22:01 5: SW: 06
2015.10.20 13:22:01 5: ZWDongle_1 dispatch 00040003032501ff
2015.10.20 13:22:01 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:032501ff
2015.10.20 13:27:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00040003028407
2015.10.20 13:27:02 5: SW: 06
2015.10.20 13:27:02 5: ZWDongle_1 dispatch 00040003028407
2015.10.20 13:27:02 4: ZWDongle_1 CMD:APPLICATION_COMMAND_HANDLER ID:03 ARG:028407
2015.10.20 13:27:02 5: ZWDongle_Write 00 13030243022503
2015.10.20 13:27:02 5: SW: 0109001303024302250383
2015.10.20 13:27:02 5: ACK received, removing 0109001303024302250383 from dongle sendstack
2015.10.20 13:27:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.10.20 13:27:02 5: SW: 06
2015.10.20 13:27:02 5: ZWDongle_1 dispatch 011301
2015.10.20 13:27:02 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130300
2015.10.20 13:27:02 5: SW: 06
2015.10.20 13:27:02 5: ZWDongle_1 dispatch 00130300
2015.10.20 13:27:02 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.10.20 13:27:02 4: ZWDongle_1 transmit OK for 03
2015.10.20 13:27:04 5: ZWDongle_Write 00 13030284082503
2015.10.20 13:27:04 5: SW: 010900130302840825034e
2015.10.20 13:27:04 5: ACK received, removing 010900130302840825034e from dongle sendstack
2015.10.20 13:27:04 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 011301
2015.10.20 13:27:04 5: SW: 06
2015.10.20 13:27:04 5: ZWDongle_1 dispatch 011301
2015.10.20 13:27:04 4: ZWDongle_Read ZWDongle_1: sending ACK, processing 00130300
2015.10.20 13:27:04 5: SW: 06
2015.10.20 13:27:04 5: ZWDongle_1 dispatch 00130300
2015.10.20 13:27:04 4: ZWDongle_1 CMD:ZW_SEND_DATA ID:00 ARG:
2015.10.20 13:27:04 4: ZWDongle_1 transmit OK for 03