List of items we still need before Transition Day for Edge devices, some of which we’re losing when the IDE is gone, some of which we don’t have with Edge devices, some of which we need to make the transition clean.
This list is about a) abilities needed for transition, b) features that we’re losing when the IDE is completely shut down or c) abilities that DTH+IDE had that Edge+App/CLI/API does not.
Ability to see Z-Wave device information in the app, CLI or API (fingerprint, clusters, security level). Currently only available in the IDE for DTH devices.
Ability to see Z-Wave routing information in the app, CLI or API. Currently only available in the IDE for DTH devices.
Ability to see ZigBee device information in the app, CLI or API (fingerprint, clusters, signal level). Currently only available in the IDE for DTH devices.
Ability to see ZigBee routing information in the app, CLI or API. Currently only available in the IDE.
Ability to transition Z-wave and ZigBee devices manually.
Ability to see and change ZigBee radio channel via app, CLI or API. Currently only available in the IDE.
Ability to reboot a hub via app, CLI or API. Currently only available in the IDE.
Ability to see hub event history via app, CLI or API. Currently only viewable in the IDE.
Ability for drivers to share informational data easier to a user (without requiring a custom capability.) Make it easier to share status of a device or details on the Information tab in the app.
Ability to see how much memory/storage is in use and available on a hub. Memory or CPU load per driver or device.
IDE DTH editor allowing edits of existing DTHs, so we can transition devices from DTH to Edge one-at-a-time.
Mechanism to help debug why some users are having so many issues with Zigbee devices going offline.
Smart Lighting app transition (IN PROCESS)
Notification when specific devices are being or have been automatically transitioned.
A menu driven system for choosing a driver during the discovery process rather than scanning everything. This would be similar to choosing the “brands” in the workflow. It is needed for LAN devices which don’t have fingerprints. Competing drivers will clash during discovery.
Post your requests and needs and I’ll add to the list above.
A menu driven system for choosing a driver during the discovery process rather than scanning everything. This would be similar to choosing the “brands” in the workflow. It is needed for LAN devices which don’t have fingerprints. Competing drivers will clash during discovery. This currently happens to my Hue driver and the ST bundled Hue DTH.
I would also say there needs to be a way for a LAN driver to disable being able to be changed to anything else. For instance, the virtual drivers can be changed to anything else, when they for sure won’t work.
I can add it, but this is more about things needed for transition or that we’re losing when the IDE is completely shut down or things that DTH+IDE had that Edge+App/CLI/API does not.
We never had Z-wave replace before. We don’t have Z-wave replace in the current DTH environment, so its not something I’m immediately concerned about for the transition.
The only spot I could see swapping a v-driver would be to migrate to a different driver from the same developer. If I made a breaking change, I could offer a second driver that migrates devices. You would have to know the internals of both drivers though.
Would it make sense that LAN drivers offered a fingerprint string as well? Drivers could be told, only allow change to other drivers with a matching fingerprint.
Sure we did. We had it for years, from at least 2014 up through 2019, although it was done at different ways at different times. It was covered in the official support documents at that time. I don’t know why it went away, it was very helpful. You’ll find lots of older threads in the forum discussing it.
I will rephrase my response from “we never had it before” to “we don’t have it now in the current DTH landscape”.
The goal of the post was to list the items that we’re going to lose on transition day or issues caused by moving from the current DTH environment to Edge.
showing the number of routines saved on the hub. There is a limit of 200 routines per hub, and we need MANY routines now that we have to recreate Webcore pistons with routines (my personal record is 8 separate routines to replace a single piston)
the same for number of saved drivers (limit is 50 per hub)
option to NOT automatically delete routines when a device is deleted. Sometimes we need to re-pair existing devices, or replace faulty devices, and is a major pain that routines just silently disappear. (Alexa handles this much better, so it IS possible).
option to display the fingerprints of a given driver. Optimally an option to simply add an additional fingerprint by the user
option to “freeze” a given driver and exclude it from automatic updates. There is no point in having drivers saved locally on the hub without any control of their update cycle.
and/or option to roll back to an older version of a driver if needed.
This was recently increased to 1,000. Give me a minute and I’ll find the staff comment. It was in a discussion about the new smartlighting plug-in, but applies to all routines/scenes.
