Trying to get a couple of Fibaro TRVs working. Did the manufacturer info fix (thanks) and I almost have full control. Setpoint, mode and actual temp feed back all working fine. I can raise and lower setpoints and put the device into “Off” but the device will not respond to a “HeatOn” and switch on when off. I have variable 2 bit 3 set so I can see the TRV LED react to setpoint and Off changes without touching it. There is no indication when I’m trying to turn it on - otherwise the display works as expected. When in “Off”, I can manually turn it on and then it starts to respond again to setpoint changes and Off request. i.e. everything but a call to switch on is working.
I have written a little bit test code to send mode requests. The problem seems to be that the request is initially successful but then I get a log message about command classes that I do not understand…
device 635 got a secure command for unsecure command class 0x22 command 0x1 m_iFrameID 30672/16853944 data 0x1 0x2
(I think command class 0x22 is APPLICATION_STATUS)
Is this another error in the default config that can be fixed?
The manual says to send a 0 for off and 99 for on for “response to basic command class”. I can’t spot anywhere in the config where might be set (I was trying to see whether I could work out anything from the Smart Implant config fixes posted on here)
Any chance you could show me exactly what you are doing to call for heat (lua etc.). Also could you send me the log file extract so that I can see exactly what your system is doing underneath?
Could you show me your variables tab?
I have no idea what a standard “scene” in a vera secure will call. the scene setup is too simplistic for that, but it is maybe a bit too smart - it displays the same image as the one I had in my first reply, and even though I just altered the heat switch to on, it actually sets the temperature as well
or now…
this is what I get i the luaupnp.log for dev 685 when the scene runs:
root@MiOS_55100763:/tmp/log/cmh# tail -f LuaUPnP.log | grep 685
08 09/20/21 13:52:13.371 JobHandler_LuaUPnP::HandleActionRequest device: 685 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 action: SetModeTarget <0x76bf9520>
06 09/20/21 13:52:13.412 Device_Variable::m_szValue_set device: 685 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 variable: ModeTarget was: Off now: HeatOn #hooks: 0 upnp: 0 skip: 0 v:0x10b7fc8/NONE duplicate:0 <0x76bf9520>
06 09/20/21 13:52:13.413 Device_Variable::m_szValue_set device: 685 service: urn:upnp-org:serviceId:TemperatureSetpoint1 variable: CurrentSetpoint was: 21.5 now: 21.5 #hooks: 0 upnp: 0 skip: 0 v:0x10b85f8/NONE duplicate:1 <0x76bf9520>
08 09/20/21 13:52:13.416 JobHandler_LuaUPnP::HandleActionRequest device: 685 service: urn:upnp-org:serviceId:TemperatureSetpoint1 action: SetCurrentSetpoint <0x76bf9520>
01 09/20/21 13:52:13.416 JobHandler_LuaUPnP::ConfirmGlobalActionRules device 685 Can’t setpoint to thermostat in Off Mode <0x76bf9520>
02 09/20/21 13:52:13.417 JobHandler_LuaUPnP::RunAction device 685 action urn:upnp-org:serviceId:TemperatureSetpoint1/SetCurrentSetpoint failed with -911/GET_LANG(setpoint_in_off_mode,ERROR Can’t set setpoint to thermostat in Off Mode) <0x76bf9520>
04 09/20/21 13:52:14.803 <0x76bf9520>
06 09/20/21 13:52:14.990 Device_Variable::m_szValue_set device: 685 service: urn:upnp-org:serviceId:HVAC_UserOperatingMode1 variable: ModeStatus was: Off now: HeatOn #hooks: 0 upnp: 0 skip: 0 v:0x10b7078/NONE duplicate:0 <0x76bf9520>
04 09/20/21 13:52:14.992 <0x76bf9520>
02 09/20/21 13:52:15.216 ZWaveNode::HandlePollUpdate node 66 device 685 got a secure command for unsecure command class 0x22 command 0x1 m_iFrameID 2992/19980216 data 0x1 0x2 (##) <0x76bf9520>
I saw one thing in the gui - when heat was turned on, the setpoint was shown as “–” it was not until the second command was sent, that the 21,5 degrees were shown.
Many thanks. Can’t spot any differences in the config. Interesting that you are getting the same message I am “got a secure command for unsecure command class” so maybe that’s a red herring.
I’ve not been sending a setpoint after an “ON”. The unit should return to the last setpoint. I note that you are getting an error - must be too quick after the “ON”. Will have a play.
Also looks like your scene is sending the same upnp actions as I am.
Does the on/off slider on the graphic work as well? Mine moves as expected, its just the TRV stays in off mode (LED white).
the slider works fine. Now when you put it like that - I have to check some more…
I did a Poll now in the commands tab, and ithe first time I get “can’t send command to node” and when I poll again, it resets the setpoint value to – and heat goes to off but stillgives “error can’t send commandto node”.
I then did heat - off, triggered the motion sensor, it turned back on and set the setpoint value to 21,5. first poll times out, second worked fine and all looks as expeced.
I know that my network is a bit flaky at times, but this is just strange.
good thing I don’t have to turn the radiators off…
Did a lot of testing last night and it seems that perhaps once in every 40 or so times the HeatOn actually works. The TRV comes on back to its original setpoint as shown by the LED. However when it fails I get successful transmission message on the graphic followed by a application busy warning. The TRV is only 2m from the Vera during testing. The off command works perfectly every time.
The log file shows that the upnp ModeStatus variable is switched before the “Heat On” job runs so if it fails the graphic will be wrong. Will probably be corrected in a subsequent poll.
Log file shows
<0x768bc520>
02 09/21/21 7:47:00.808 ZWaveNode::HandlePollUpdate node 40 device 641 got a secure command for unsecure command class 0x22 command 0x1 m_iFrameID 59482/27609216 data 0x1 0x2 (##) <0x768bc520>
02 09/21/21 7:47:00.809 ZWaveNode::HandlePollUpdate_Application_Status got APPLICATION_BUSY for 40 status: 1 time: 2 <0x768bc520>
FYI I’ve developed a helper device to supervise the heat on request. It sends the request, waits for a min, polls the device every 2 mins to check and when it gets a successful poll, checks whether the mode has actually changed. If it has not reached the target, it resends the mode change. It repeats this for a given time. Seems to get there in the end but generally gets there after 5 mins or so. Seems a horrendous time but probably good enough for heating control. If you ever get problems and this would help give me a shout.
I’ve emailed Fibaro to see whether they have seen this before. The intermittent success suggests there’s something like a timing problem / wake up problem when the device is OFF between the Vera and the TRV. Will keep on this as the TRV is such a cool device otherwise.
Also the Vera gets a successful return for the HEATON mode change but the device has not actually changed. Only a subsequent poll reveals that the mode change has not been accepted.
Regards
Richard
1 Like
Best Home Automation shopping experience. Shop at Ezlo!
