in the install section, there are these two lines (but not with the new line numbers).
I'm testing the following extended handling of the WakeUpIntervalReport . Now I must wait min. one day to see if it works for the next unexpected wakeup reset.
def zwaveEvent(hubitat.zwave.commands.wakeupv2.WakeUpIntervalReport cmd) {
if (logEnable) log.debug "Last State receivedWakeInterval - Wake Up Interval Report recived: ${cmd.toString()}"
// show and reset, if unwanted interval change reported
nTime = new Date()
int recWU = cmd.seconds as Integer
state.receivedWakeInterval = "$recWU at $nTime"
if (recWU != state.wakeUpEvery) {
state.ComCount = state.ComCount + 6
state.ComWake = true
log.info "${device.displayName} - Configure storing wakeUpInterval for next wake '$state.wakeUpEvery'seconds AND configuration flag is $state.configrq"
}
}
Have an issue using this driver.
When using the "generic z-wave thermostat" driver for my pop/danfoss TRV radiator-thermostat, i have access to the "temperature" parameter when using rule machine. (i can trigger actions based on the temperature value changing, etc)
However, using this "popp/danfoss" driver the "temperature" parameter is not available to rule-machine. I guess there is something in the driver preventing this. How can i make this value be available in the popp/danfoss driver?
thanks
There should be no reason why. Which temperature are you tring to use, the radiator temperature or the setpoint temperature
i can access and control the setpoint- that's not an issue.
But with driver set to "popp/danfos", the device (shown here as "radiator") is not an option within rule-machine
a quick glance at the driver and i saw this:
capability "Actuator"
capability "Sensor"
capability "Thermostat"
capability "Battery"
capability "Configuration"
but didnt see a "temperature" capability. But the temperature value is present and correct in the device view.
Have i got a corrupt or older driver?
No, part of the thermostat capabilities is temperature. Its an else fix just add the capability to the driver.
Have you tride using the capability thermostat in RM to see if the other sensors show.
i did eventually find away but had to access the value via "custom attributes".
i did try tinkering with the driver adding the capability but it showed as an error. I've yet to understand and learn the correct way to write driver code so this is beyond me at this time.
i dont want to create bigger problems by creating bad code.
Not sure why this is not appearing as a standard "temperature" attribute.
Whatever the case, i got it doing what i wish now.
I also come from VERA with some POPP thermostats. I'm interested in your experience with the wakeup interval. Does it stay stable?
This driver works mostly fine for my devices. But, occasionally (mostly ~once a day), they reset the wakeup interval from the pref. 300s to the default 1800s. According to the manual
this happens, if the communication is lost for longer time. But the driver log shows normal behaviour before the notification of the resetted interval is shown. So I assume a problem of this device with zWave7 or of C-7, because in my former VERA installation the short wakeup interval stayed stable.
So my only option was to make a modification (it's more a tinkering because I don't have real know how in drivers and groovy):
1: Automatically set the correct wakeup intervall after reset happens.
Problem: It takes two cycles to come into effect: Only acceptable for one of my locations.
2: At every wakeup set again the wakeup interval.
Problem: Every second wakeup is skipped. So if I want a 10 min. wakeup interval, I need a preference of 5 min. But in the case of the interval reset, no wakeup cycle is lost. Do not know if this way is good for the battery life.
Since discovering and installing the popp/danfoss driver, it has allowed me to set the wake-up interval to prevent the device going into fault state after a period of time. I had to do a reset and install as new device to transfer to the hubitat system. Initially i only had the generic driver and that led to the device going offline in an error state as i hadnt set the wake-up interval/time.
- Set wake-up interval parameter in the device driver panel. (mine is 30 minutes)
- click save.
- then click configure (which it will do on its next wake up)
- You could also change the temperature on the device itself which initiates communication with the hub where it will then get its configuration settings transferred.
Being a non-PLUS z-wave device (do they make a PLUS version??) there may be some compromises. Even before (vera days) it didnt require regular wake-ups as it was only set a couple of times a day. The batteries used to last around a year like this so interesting to see how it fairs up now. Mind you, i did sap 25% of the battery during the set up and learning process as i tried to figure out everything i've said above.
I've set the wake-up interval to 30mins so i can take a reading of the room temperature at regular intervals. Obviously, driving the valve mechanically is the biggest drain on the batteries,
Useful tip?
Does anyone know if it has an automatic regular open/close cycle to reduce the likelihood of the valve seizing up? (maybe i dreamt reading that somewhere?) I put code in my old vera that the thermostat would open fully (whilst the heating was not running) once per week to keep the moving parts moving.
Ok. I understand. The default wakeup interval of the POPP is 30 min and your preference is the same. So there is no possibility of a reset.
I need for my thermostats a 10 min interval (with vera the batteries lasted about 1/2 year). That's another situation. I can set the interval with the driver and it works some hours or days, but it resets "automatically" from time to time.
Tip:
I'm pretty sure, that the device itself opens the valve fully once a week. There is no need to do that per router.
Hi guys, perhaps somebody could help me a bit with some issues I encounter with POPP 701721 .
I just installed a POPP 701721 TRV and paired with HE C-7 running 2.3.3.140.
-
After pairing I'm selecting the proper driver - so thanks to the Mark - (Danfoss Living Connect and POPP Radiator The...) - tried both the raw link and the version from GitHUB (think they are the same though) and save the device.
-
Then I press 3 seconds the button on the TRV (to exit pairing mode) and it's displaying correctly the temperature and zigbee network icon (not flashing). Then I set heatingSetpoint to 22C and click configure. Right now the device enters in Maintenance mode (and stays like that), so I press again the button 3 seconds to exit maintenance mode, it's exiting the maintenance mode but now the zigbee network icon is flashing and seems like there's no communication any more between HE and the TRV.
-
I try now to repair the TRV to the hub (without removing it as a device from HE), the hub sees it and then the zigbee network icon stops flashing - so communication established again.
-
at this point I don't touch any config any more but after about a minute or two, the TRV enters maintenance mode again. If I exit maintenance mode, zigbee network icon flashing again (left it like that for a night and in the morning still flashing) + no communication from the HE to TRV.
-
If I try pairing it again (without removal) the zigbee icon shows connected but the after few minutes it goes into maintenance again (like in a loop).
I've also reseted the device according to manufacturer's procedure (removing a battery and pressing the button before re-inserting the battery + release button when stops flashing), remove it completely from HE several times and added it as a new device but I always end up in the same loop.
I have the device since about 4-5 days and in the first 3 days it was working properly.
Did any of you encountered such behaviour?
Should I try to control it via MQTT?
Any suggestions are welcomed!
Thanks guys!
John
PS, also pasting here the latest logs:
dev:712022-11-18 09:04:17.393 PMwarndebug logging is: false
dev:712022-11-18 09:04:17.391 PMinfoKitchen radiator - Configure storing wakeUpInterval for next wake '300'seconds AND configuration flag is true
dev:712022-11-18 09:04:17.384 PMdebugprodID - null
dev:712022-11-18 09:03:03.268 PMwarndebug logging is: false
dev:712022-11-18 09:03:03.250 PMinfoKitchen radiator - Configure storing wakeUpInterval for next wake '300'seconds AND configuration flag is true
dev:712022-11-18 09:03:03.235 PMdebugprodID - null
dev:712022-11-18 09:03:02.407 PMdebugsetHeatingSetpoint(Double deg) - Storing temperature for next wake 22.0
dev:712022-11-18 09:02:48.087 PMwarnNon-parsed event: catchall: 0000 0013 00 00 0040 00 7686 00 00 0000 00 00 818676AC2DD4FEFFF9E3B480 - cmd = 'null'
dev:712022-11-18 09:02:30.650 PMwarndebug logging is: false
dev:712022-11-18 09:02:30.648 PMinfoKitchen radiator - Configure storing wakeUpInterval for next wake '300'seconds AND configuration flag is true
dev:712022-11-18 09:02:30.640 PMdebugprodID - null
dev:712022-11-18 09:01:54.974 PMwarnNon-parsed event: catchall: 0000 0013 00 00 0040 00 BCB7 00 00 0000 00 00 81B7BCAC2DD4FEFFF9E3B480 - cmd = 'null'
dev:712022-11-18 09:01:54.698 PMwarndebug logging is: false
dev:712022-11-18 09:01:54.696 PMinfoKitchen radiator - Configure storing wakeUpInterval for next wake '300'seconds AND configuration flag is true
dev:712022-11-18 09:01:54.687 PMdebugprodID - null
dev:712022-11-18 09:01:06.737 PMinfofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0003,000A,0020,0201,0204,0B05", outClusters:"0000,0019", model:"eT093WRO", manufacturer:"D5X84YU"
dev:712022-11-18 09:01:06.276 PMinfofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0003,000A,0020,0201,0204,0B05", outClusters:"0000,0019", model:"eT093WRO", manufacturer:"D5X84YU"
dev:712022-11-18 09:01:05.768 PMtraceZCL version:03
dev:712022-11-18 09:01:05.766 PMtraceSoftware Build Id:01.12.0008 01.12
dev:712022-11-18 09:01:05.765 PMtraceModel:eT093WRO
dev:712022-11-18 09:01:05.764 PMtraceManufacturer:D5X84YU
dev:712022-11-18 09:01:05.344 PMdebuggetting info for unknown Zigbee device...
dev:712022-11-18 09:01:05.276 PMinfofingerprint profileId:"0104", endpointId:"01", inClusters:"0000,0001,0003,000A,0020,0201,0204,0B05", outClusters:"0000,0019", model:"eT093WRO", manufacturer:"D5X84YU"
dev:712022-11-18 09:01:04.738 PMtraceModel:eT093WRO
dev:712022-11-18 09:01:03.713 PMinfoZigbee parsed:[raw:catchall: 0000 8005 00 00 0040 00 9393 00 00 0000 00 00 0A0093930101, profileId:0000, clusterId:8005, clusterInt:32773, sourceEndpoint:00, destinationEndpoint:00, options:0040, messageType:00, dni:9393, isClusterSpecific:false, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[0A, 00, 93, 93, 01, 01]]
There z-wave devices
Hi Mark and thanks for your reply.
You say I would need to pair it with Hubitat as a Z-Wave device?
It says clearly on the product it's a zigbee version.
The driver wasn't developed for that version, must be new
Have you tried any of the stock thermostat driver's
Like others, my Popp z-wave trv seems to work well with this danfoss / Popp driver, but the wake up interval keeps getting reset to 1800 (30 mins) when I really need it to stay at the minimum of 600 to be of any practical use. Has anyone found a way of making the trv permanently keep a wake up interval of 600? Any suggestions welcome.
I've modified the driver of MarcCockcroft for my needs. At each wakeup the wakeup-interval is providently set to the preference value. Disadvantage: The device skips one each wakeup (a preference of 5 min leads to a real wakeup interval of 10 min).
I've tested to set the wakeup conditionally (when receiving the 1800s interval report). But this correction takes up to 2* 1800s to come into effect. This is not sufficient for me.
Thanks for your informative reply. The Mark Cockcroft driver I'm using seems to work fine in all other respects and as I don't know anything about writing/modifying driver code I think I'll leave it as it is for the moment. 600 works for me as a compromise between functionality and battery life.
I can't figure out if there's a regular pattern to the wake-up interval reversion to 1800. If this device does not exhibit this behaviour on other platforms, that suggests the problem is either with the driver or the HE platform (or both).
My simple/crude workaround is to send a 'configure' command to the device every night at 2 am. This works as long as the 'problem' doesn't occur more frequently than this. So far so good.
As a side issue, is it possible to send only a 'set wake up interval' command to the device rather than a catch-all 'configure'? It would be useful to be able to do this within a timed rule; also for other devices.
Hi John,
Did you ever figure out what the problem was? I have exactly the same issue with my POPP Zigbee TRVs now. Any advice?
Thanks,
Marek
Hi Marek, nope, unfortunately I haven't figured out and completely dropped the solution.
Take it easy!
Ive put this around the 191 line, inside the battery refresh request wich runs every 7 days if no battery report.
It would actually be better to put it in the next if to set the clock
cmds << zwave.wakeUpV1.wakeUpIntervalSet(seconds:state.wakeUpEvery, nodeid:zwaveHubNodeId).format()
cmds << zwave.wakeUpV1.wakeUpIntervalGet().format()
