On the device not that I’m aware of, st don’t support it, how do you know it needs updating
I don’t know, it works fine. But imagine on future Samsung make changes… And Eurotronic doesn’t work. Eurotronic doesn’t have native support, is with a dh… If developer doesn’t make a new dh all thermostats will be as a rock on a table.
Thanks
Hi Guys
I’ve been testing this DH and have trouble with understanding how it is supposed to work.
My test case:
20.5C is reported by the handler.
I started with Eco mode (set to 19C in the options) enabled. Valve - 0%. OK
I disabled Eco and set heating setpoint to 21C, waited about 1min. Valve - 0%.
I was adding 0.5C and waited about 1min after each step until setpoint reached 23C. Valve - 0%.
23C, valve 1%.
23.5C, valve 11%, 19% after a minute and 20% after another minute.
And started decreasing the setpoint.
23C, valve 8%, then 6% after a minute, then 5% after another.
22.5, valve 0%.
Actual temperature went from 20.5C to 20.87C during this test.
Can someone clear this up for me? What am I missing? Why the valve is opened so late (23C when the actual temperature is as low as 20.5C)?
As a side note I could add then when I tried with physical + button on the valve it was immediately open to 35% and closed almost immediately by the handler I guess (I noticed both values in ST classic app).
Thanks,
cob
did you refresh the device?
Thanks
What do you mean by “refresh the device”? I just updated the setpoint temperature and waited about a minute afterwards. Note that when I went below 23C the valve closed although it was still only 20.87C.
Just a little side note - I have four of these in four rooms and they all behave in similar way.
On app, refreh, perhaps the valve it’s open but not show on app…
I checked valve status in the logs (on the “Recently” tab in the ST app) not on the main page of the DH. And put my hand on the radiator so I am pretty sure it was not getting warmer until the setpoint reached 23.5C :-).
I am using the latest DH posted in this thread. I will try with the others and with the stock one.
hey guys…
tanks for the great DH!
is there any chance to get the DH run for the new app? It works great for the classic app, but im using the new one since a few weeks and this is the only device which isn’t working fine for me.
and maybe a stupid question, but can someone explain the cooling function in a few words
Thanks a lot…
Thanks for the work, with this DH. I’ve been working through it as I eventually want to try and use the ability to configure the valve. Very occasionally I’ve had one of these respond so slowly to the temperature change, that the room has overheated by around 5degrees.
For now I’m troubleshooting one particular valve that I seem to be having a comms problem with. I was doing some manual sets on the TRV itself. I unlocked it and also set boost, neither of which showed up as changes on the device page.
I did see this in the logs:
1:43:28: debug Non-parsed event: zw device: 0F, command: 7503, payload: 00
11:43:28: warn Exception ‘java.lang.NullPointerException: Cannot invoke method and() on null object’ encountered parsing ‘cmd: 7503, payload: 00’
If I’m correct this relates to the manual unlock. If anyone can explain, I’d be grateful.
Yeah, it’s for lock/unlock. Not related to the issue. You can fix the exception though by adding:
def zwaveEvent(physicalgraph.zwave.commands.protectionv1.ProtectionReport cmd) {
createEvent(name: "lock", value: cmd.protectionState, descriptionText: "Lock mode: ${cmd.protectionState}")
}
I took a look at different home automation forums and people complain about this TRV overheating or heating to late. Exactly what I described a few posts above. I experienced overheating in one room as well - there was over 23C, I set eco mode (19C) and left the room. Four hours later the radiator was still hot.
I wouldn’t buy them again. But since I did I’m going to add direct valve control to the DH and test with it. But I don’t expect too much. Looks like they are flawed in some way.
All TRV should have temperature settings when to open and when to close relative to target temperature.
They are quite basic things as they are designed only as actuators. They don’t have features like temperature gradient recognition and AI based planning. But as they should be used as a Connected device, they can be controlled with ST like that. You can define rules or rewrite the DH for relative heating and cooling points. Target + 1 turns off. Target - 1 turns on. But you just show the target in the app and the TRV is controlled with different setpoints. To open at Target - 1, change the set point at that temperature to Target +3, or do direct control of the valve to open. And to close do the opposite way around.
I have different TRVs and planning to implement these settings to the DH what I am using with those. The manufacturer hasn’t provided option for the relative cooling and heating setpoints.
(It is a bit like the switch state on many smart bulbs or sockets when you power cycle it, many has precoded values, some has options to change it, but might not with ST.)
They have builtin thermostat and you can set the setpoint on them. The problem is that it does not seem to work properly (e.g. starts heating when the setpoint is set like 3C above the current temp or continue heating even it reports temperature lower by a few degrees than the setpoint). So like I said, I am going to try with direct control the valve in the way you described (-1/+1).
There is an AI SmartApp for controlling heating. Search for it. You might can get something decent with that as an addition.
Thanks @coberty I shall add that event for the lock / unlock into my code later. I don’t like loose ends and I spotted that today when operating the valve manually.
Incidentally, I’ve had the heating on all day today and the control has been very good. All the thermostat readings have been very close to the setpoints all day.
They’re definitely not as responsive as they should be, when starting the heating from cold. I’ve only had a couple of instances where they’ve totally lost control. I read a post somewhere else where the poster manually set the valve when the temperature was close to set point but then put it back into auto. I was thinking of trying that first before I go ‘fully controlled.’
@coberty I’m certainly interested in seeing if you make progress. I’ll let you know if I do.
One more thing to note is, I believe the ‘off’ is more like frost protection, where the valve stays partially open, so that wouldn’t work anyway.
I added the ability to switch the TRV into direct valve control, tonight.
I’ve added a button into the device handler that, when pushed, sets the mode correctly. The TRV has reported the status back
23:21:23: info RepRecived ThermostatModeReport(reserved01: 0, mode: 31), dvc, dvc
23:21:17: trace DVC On [ThermostatModeSet(reserved01: 0, mode: 31), ThermostatModeGet()]
I actually took out the summer & cooling settings as I didn’t really need them. The ‘off’ setting is frost protection, according to the manual so that will be fine for the months the heating won’t be used. I’ve also changed some of the mode names to better suit me.
I’ll be trying to write some webcore pistons tomorrow. I’ve ordered a couple of external thermostats to have a go at using off-sets as well.
Looks like I have a bit of work to do to expose the offset configuration to webcore, to work with external thermostats. The documentation does say you can work with the temperature directly but I’m not sure I want to do that.
Also, the valve setting command that I added doesn’t allow me to enter the value. I’m presuming this needs an attribute added.
Still getting parse errors after adding the event handler for the lock setting. I’m not entirely sure how to fix that. Seems to be the way the report arrives. No biggie for now but on my list.
I had a good play with the direct valve control operating mode last night and all seems ok, switching between modes and logging. All the other functionality has been maintained.
My plan is to try to expose the setvalve attribute to webcore tonight and then try to write some code to control the valve, based on the temperature as set by the offset, once configured.
Sorry,
forgot about one thing.
In the parse() method replace
def cmd = zwave.parse(description)
with
def cmd = zwave.parse(description, [0x75:1])
Let me know if it works for you.
Thanks.
Thanks @coberty. That has worked, with some additional logging commands I entered.
Also, success. I now have the valve under direct control and can switch between modes:
The following logging is taken while running a webcore piston I’ve created tonight. I’ve also created a custom command with parameter for temperature offset as well, although I need to do some work to see if it works with decimals.
21:19:34: info RepRecived ThermostatModeReport(reserved01: 0, mode: 1), heat, heating
21:19:33: info RepRecived SensorMultilevelReport(scale: 0, sensorValue: [8, 92], precision: 2, sensorType: 1, scaledSensorValue: 21.40, size: 2)
21:19:31: info RepRecived - SwitchMultilevelReport(value: 0) - - Valve open ‘0’%
21:19:29: trace POLL [SensorMultilevelGet(), SwitchMultilevelGet(), ThermostatModeGet()]
21:18:56: info RepRecived ThermostatModeReport(reserved01: 0, mode: 1), heat, heating
21:18:52: trace heat [ThermostatModeSet(reserved01: 0, mode: 1), ThermostatModeGet()]
21:18:52: trace DVC Off
21:17:21: info RepRecived - SwitchMultilevelReport(value: 10) - - Valve open ‘10’%
21:17:19: info RepRecived ThermostatModeReport(reserved01: 0, mode: 31), dvc, dvc
21:17:17: trace Setting Valve to 10%, [SwitchMultilevelSet(dimmingDuration: 0, value: 10), SwitchMultilevelGet()]
21:17:15: trace DVC On [ThermostatModeSet(reserved01: 0, mode: 31), ThermostatModeGet()]
Tomorrow’s job is to grab the trv during warm-up and close the valve. I’m happy that once the temperature is close to the setpoint and the valve is not open / close to closed, I can hand the control back. I will need to consider those anomalies I’ve had where the trv has ‘lost control’ but, all in all, nearly there.
Today, I’ve created new preferences for polling, valve reporting, temperature reporting and battery reporting. This is so you have the option to turn off polling and have the device report at thresholds, as per the documentation.
I’ve not been able to get the notification capability working as I wanted to see if that was the correct way to handle system and power notifications. I’ll have another go at that tomorrow.
I need to check that, with the changes I’ve made, the new valve control commands are exposed to webcore but they are working from the smartthings app.
I’ve tested the configuration set. There are a couple of bugs to iron out. If anyone is interested in the result I’ll upload it to githib later.
Changes so far:
Added direct valve control mode (auto) for when the TRV is in mode 31
Added command to set valve
Amended ‘off’ state to ‘frost’
Amended ‘heat’ state to ‘comfort’
Removed summer mode
Added graphic for configdue tile
Added battery graphic
Added configuration preferences to
- disable polling
- set temp report threshold
- set valve report threshold
- set battery reporting period
Sure. Post your work. I’m interested.