Haven’t edited that driver since adding it a couple years ago. Also don’t see anything relevant commented out and the fingerprint is not commented out.
1 Like
Which one was the original driver?
Only compatible drivers with the device appear in the “switch driver” option. This means that drivers must have the device’s fingerprint or a generic one that supports your driver.
Also, something important to note is that, when we change the driver of a device, the configuration lifecycle isn’t triggered again by default, the developer would need to explicitly call this function. Otherwise, any special configuration during this process won’t be executed.
To check if the device doesn’t actually work with a certain driver, you need to delete it for a fresh installation.
For powered devices, I run the same configuration sequence in driverChanged events as I do added. This makes sure the device is setup properly. You also need to run the default handlers to set provisioning correctly.
Yeah, I meant “by default” as part of the switch driver process. Sorry for the confusion, I just edited my comment.
1 Like
Sorry, I stupidly didn’t note that.
I have installed a custom edge driver zigbee light multifunction Mc
It works well with that, but like I say it doesn’t work properly with standard stock edge driver which is offered as zigbee switch
I think the fingerprints of the device are _TZ3000_riwp3k79
But I can’t see that in the ide any more
1 Like
Interesting to note that the stock drivers for devices that have been migrated are now included in the list of installed drivers. (From the @TAustin info viewer)
2 Likes
Anyone else notice any oddity with Sonoff ZBMini after they were migrated to Edge?
I had zero issues with them prior to the migration, but now I sometimes see when a routine switches the switch off instead of going from being on to ->OFF instead it goes from being on to ->OFF->ON->OFF
I have an alexa routine and a virtual switch to announce the heat going on and off, and it also announces this sequence.
Any clues what could be causing this?
|Name |SONOFF 01MINIZB|
|Mfg Name |SmartThingsCommunity|
|Room |Heat|
|Presentation ID |dc51981a-71db-3f67-a30b-150d778cd741|
|Type |ZIGBEE|
|Parent Name |SmartThings v3 Hub|
|Driver Name |Zigbee Switch|
|Provisioning State |PROVISIONED|
|Local Execution |yes|
I’m already seeing WebCORE pistons starting to fail, even though they were supposed to be safe until end of December. Most of my devices have still not migrated. Anybody else noticing this?
Yes, any WebCoRE piston I have controlling my Iris garge door opener fails, I think it might have to do with the DTH being switched to and Edge Driver for the garage door opener.
1 Like
Further oddness…
The 9.15pm routine to switch downstairs heating resulted in off,off,on appearing in the history in that order.
But the app shows that the status of the switch is “off” despite the last entry showing as on.
This is annoying as I had been controlling heating with great success for the last year, it’s casting a shadow on reliability, and I’m struggling to see how to troubleshoot it.
Is there a better edge driver for this other than Smartthings “Zigbee Switch”?
Why is the device turning on and off so many times within the same minute? At 6pm for example. What rules would you have for a heater where its oscillating like that?
I don’t think you can trust 100% that the events in history are exactly in the order in which they happened, at least for the same few seconds. Its very likely the 9;15 sequence went 1 off, 2 on, 3 off, but the events to the cloud arrived as 1 3 2.
1 Like
I find the app makes a mess of sorting by latest time and when more than one entry is shown for the same timestamp the one at the top is the earliest.
3 Likes
the 6pm entry is partially explainable, i turned it on manually when alexa announced the heat was off.
the 9.15pm entries are not explainable, I did not intervene at all.
- What are your routines for this device? Any chance you have two rules fighting at the switching point?
- If your device was auto migrated to Edge, perhaps the routines themselves are screwed up and you should just delete and recreate them.
- I would also recommend for using a virtual thermostat device to control the switch. You want the range around the switching point to be buffered so it doesn’t oscillate. Or of course you could have rules that have a few degrees difference. But thermostat devices have all that built in.
1 Like
Hmm, for me it’s a piston that only controls non-Edge devices and is triggered only by mode changes and times. The piston is currently failing to trigger at all, so there’s clearly something broken.
Routine is simple and time based
I also have a separate routine that triggers a virtual switch which is used for alexa announce function
I been running my Sonoff ZBMinis with the “ZigBee Switch Mc” driver for many months with no issues.
1 Like
You may have got the wrong impression. Groovy Smartapp execution, which includes webCoRe, will cease on Dec. 31st. Pistons on the other hand could experience issues if a device changes from DTH to Edge where capabilities used in the piston might not be available in the Edge Driver. That is one possibility.
1 Like
Hmm.
I have just installed that driver and ST app does give me the option to switch to it.
Instinctively I’m inclined to use the stock driver, but if this oddness continues I’ll switch to the Mc driver, even thought it’s classified as beta.
1 Like
I could not get the stock driver to work with my ZBMinis and @Mariano_Colmenarejo was nice enough to modified it so it worked with the ZBMinis.
I have been using Edge Drivers for over a year and have found the community developed drivers to be indispensable.
2 Likes