Its not so much the coding conversion but the testing in “production” environments. Each conversion would require aquiring, debugging and testing each and every device (with different firmwares, etc) is a pretty difficult task, esp for products you don’t have any control over. Never mind all the various implementations people have them in. And as they are no longer in the hardware business, they have to justify those costs with corresponding sales numbers ($0 for other companies products)…
I too purchased a Hubitat last year but so far have not felt it reached the level of sunsetting my ST implementations. ST has a high WAF for me. I’d be interested in hearing your thoughts after you get it up and running.
One observation, unlike the previous groovy dth, where codes are shared and easy for people to learn and customized, the Edge DHT work like a close source project, where people doesn’t share their code, that in a way make the adoption / migration slower.
There are many many more people who are missing out on custom drivers because it involves copy/pasting custom code today. Being able to subscribe and click to install will make it easier for end users to install custom drivers.
Only install drivers from companies or developers you trust. Even with open source, unless an individual/group is reviewing the code, then you can get malware.
How are users going to change to use Edge drivers when Groovy stops working? Will you swap our devices from using DTH’s to Edge drivers automatically, or will we have to manually uninstall and reinstall each device individually?
Many of us on here not only read, but modified code to suit our own needs.
I can’t help but feel that ‘closed source by default’ is a step backwards.
It should be open source by default, with the option for commercial operations to distribute closed source code.
My biggest concern about the new Edge platform is, with everyone rushing to just get their driver out, we’ll get a bunch of plain vanilla drivers that lack thoughtful capabilities that make the platform useful.
See my post today regarding changes made to ecobee which deprecated some very desirable capabilities that created a great automation ecosystem with ST and Classic.
Once you are installing the code by subscribing to someone else’s channel, there’s no way to know for sure what’s in it, just like downloading an app from an App Store. you have to trust the persons reputation.
The only way around this is if the person makes the code available and you put it into your own channel. But that’s a lot more work than most customers want to do.
So I think closed by default is how most people get most software. Like over 90% of phone apps. You may prefer the other way, but I don’t see anything unusual in smartthings having that architecture. FWIW…
Yeah there’s a whole host of IDs the Keen vents show up as - depending on which version the vent is. AFAIK they’re all functionally identical. How do we get multiple fingerprints added?
Wonder what they’re going to do about Peanut plugs. Half the time they don’t properly respond with an ID when queried.
Edit - just checked mine - they’re all ‘SV01-612-MP-1.1’ units. I’ve also seen ‘611’ variants in the wild as well. Also, from what I’ve seen in researching the issue (had to do this research to make mine work with Homeassistant - Zigbee2MQTT didn’t recognize mine either.) when you see 1.x it is a fair assumption that you also need all ids that include integers between .0 and .x
So while they have: SV01-610-MP-1.1
THey also need: