Thanks, I am happy to test that once the driver is available via firmware update. I can even mail it to you for testing if need be since I don’t use it that often anyway since presence was absolutely horrible in ST.
What's the difference between V2 and V3?
V3 uses HA profile clusters, V1 and V2 use ST custom clusters and commands.
As near as I can tell V2 and V3 have the same case, at lease from the pictures.
Remotec zfm-80 teaser, in the next release...
includes hardware auto shutdown for intervals greater than one minute, and software shutdown for intervals < 60 seconds.
Good for fireplaces and DIY garage door controllers.
3 Likes
Can you please add a general relay driver with similar settings? I use the generic one in ST. I have a Qubino Flush 1D, ST DH in the link, and a FS20Z-1 that I will eventually move over to Hubitat.
Sure, until folks give me some fingerprints for it, you’ll have to manually switch to it.
I have one that works well for the zwn-rsm2 it may work for you as well
/*
Enerwave Dual Load ZWN-RSM2
*/
// for the UI
metadata {
definition (name: "Enerwave Dual Load ZWN-RSM2", namespace: "hubitat", author: "matt") {
capability "Switch"
capability "Polling"
capability "Configuration"
capability "Refresh"
attribute "switch1", "string"
attribute "switch2", "string"
command "on1"
command "off1"
command "on2"
command "off2"
}
}
// 0x25 0x32 0x27 0x70 0x85 0x72 0x86 0x60 0xEF 0x82
// 0x25: switch binary
// 0x32: meter
// 0x27: switch all
// 0x70: configuration
// 0x85: association
// 0x86: version
// 0x60: multi-channel
// 0xEF: mark
// 0x82: hail
// parse events into attributes
def parse(String description) {
log.debug "Parsing desc => ‘${description}’"
def result = null
def cmd = zwave.parse(description, [0x60:3, 0x25:1, 0x70:1, 0x72:1])
if (cmd) {
result = createEvent(zwaveEvent(cmd))
}
return result
}
//Reports
def zwaveEvent(hubitat.zwave.Command cmd) {
createEvent(descriptionText: "${device.displayName}: ${cmd}")
}
def zwaveEvent(hubitat.zwave.commands.basicv1.BasicReport cmd) {
log.debug "BasicReport $cmd.value"
def map = [name: "switch1", type: "physical"]
if (cmd.value == 0) {
map.value = "off"
}
else if (cmd.value == 255) {
map.value = "on"
}
//refresh()
return map
}
def zwaveEvent(hubitat.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd) {
//[name: "switch", value: cmd.value ? "on" : "off", type: "digital"]
log.debug "SwitchBinaryReport $cmd.value"
}
def zwaveEvent(hubitat.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd) {
//log.debug "MultiChannelCmdEncap $cmd"
def map = [ name: "switch$cmd.sourceEndPoint" ]
if (cmd.commandClass == 37){
if (cmd.parameter == [0]) {
map.value = "off"
}
if (cmd.parameter == [255]) {
map.value = "on"
}
log.debug "Processed zwave message: $map"
map
}
}
// handle commands
def refresh() {
delayBetween([
log.debug("refreshing s1"),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:2).format(),
log.debug("refreshing s2"),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:2).format(),
//zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:2, commandClass:37, command:2).format()
])
}
def poll() {
delayBetween([
zwave.manufacturerSpecificV1.manufacturerSpecificGet().format()
])
}
def configure() {
log.debug "Executing ‘configure’"
delayBetween([
zwave.configurationV1.configurationSet(parameterNumber:4, configurationValue: [0]).format() // Report reguarly
])
}
def on1() {
delayBetween([
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:1, parameter:[255]).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:2).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:2).format(),
])
}
def off1() {
delayBetween([
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:1, parameter:[0]).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:2).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:2).format(),
])
}
def on2() {
delayBetween([
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:1, parameter:[255]).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:2).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:2).format(),
])
}
def off2() {
delayBetween([
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:1, parameter:[0]).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:1, destinationEndPoint:1, commandClass:37, command:2).format(),
zwave.multiChannelV3.multiChannelCmdEncap(sourceEndPoint:2, destinationEndPoint:2, commandClass:37, command:2).format(),
])
}Fingerprint for Qubino is the following. Got it from the DH I had posted. Thanks!
fingerprint mfr: "0159", prod: "0002", model: "0053"
fingerprint deviceId: "0x1001", inClusters: "0x5E,0x86,0x72,0x5A,0x73,0x20,0x27,0x25,0x85,0x8E,0x59,0x70", outClusters: "0x20"
1 Like
done…
1 Like
The issue here is very likely a timeout on the hub's side, because it hasn't heard from the sensor often enough.
The link you gave has one post with a short summary of why the Xiaomi devices probably get dropped. An endpoint timeout, and then the hub drops the device. The poster's solution was to a policy that increases the timeout.
He also mentions sending a configure reporting command to the sensor to increase its frequency of attribute reports, but I know for a fact from my personal testing that Xiaomi devices just ignore configure reporting commands.
They all consistently send a battery voltage report every roughly 50-60 minutes, so if there is some way to increase whatever timeout there is on the Hubitat to be over 60 minutes that should hopefully fix the dropped connection problem.
Note that in the ST device handlers, there is a "checkInterval" sendEvent called when the sensor is newly paired (when installed(), configure() or updated() is called). This is specific to ST's Health Check feature, and I doubt will have any effect if used in a Hubitat device driver.
My experience so far is that any of my Xiaomi sensors have their connection dropped by the Hubitat after an hour, probably right before the first battery report. It would be nice to know if there's any way to adjust that timeout, because on my ST hub, all of my various Xioami devices have never had their connection dropped.
3 Likes
Any luck with the St Presence sensor V3?
It was odd that SmartThings V2 device handler is HA and is cloud based. Goes crazy when SmartThings has an outage.
but the older versions are local.
I don’t have one of these devices, but I’ll get one here shortly.
Unless they are mistaken but I could find no other reference for a 3rd version.
version 2 made by Centralite and discontinued. This was a local device handler
no longer being sold.
version 3 the current version made by Samjin. This is the cloud only based device HA device handler
my Case says M/N STS-PRS-250:
but in the store is referred to as the model F-ARR-US-2 being sold in the SmartThings shop online.
The only device handler that appears to work for it is “Arrival sensor HA” which is cloud based
The regular “Arrival Sensor” local device handler that is local does not work.
So to be clear all of mine are version 3
My hub just arrived today so will try them out.
(edited my post to reflect correct info apparently there are 3 versions)
There is a version 1 device, it had a different case than the present device. We currently have a driver for the discontinued v1 and v2 devices, the v3 or current device won’t work until we write the driver for it, which shouldn’t take very long.
learn something every day must have been very short lived.
then mine are version 3
I got the STS-PRS-250 to paired as device. Manually assigned the driver but I’m not getting and thing from the sensor. No battery, no presence status.
they are version 3
I do not think he has released version 3 yet
I just got the latest 250 model working yesterday, it doesn't work the same way as the older models, it will have a dedicated driver which will be in the next platform release.
3 Likes
Has anyone paired the Qubino Z-Wave Plus Flush 1 Relay Module ZMNHAD3 yet? I would expect it to work using the upcoming relay driver that @mike.maxwell created , however this device also has a temperature sensor option and other features and it would be great if there was a driver for it. It also has specific device settings as mentioned in the manual. @ericmaycock created the ST driver located here.
This device is on my list to port over from ST, but it will be one of the last.
have you tried doing the physicalgraph edits?
I have a ZMNHID3 on it’s way. Hoping that is all that’s needed.
likely the same DH just the ZMNHID3 comes with the temperature sensor.
