How to convert HS3 devices to HS4

[rmasonjr]

So, if you have a plugin that has created HS3 devices and is running in both HS3 and HS4, how are you going about converting those devices to HS4?
Are you creating new HS4 devices and somehow maintaining the reference numbers so the events do not get borked?

I'm thinking of a startup process that:

1. Get a list of all my plugin's HS3 devices (using the old Scheduler.Classes.DeviceClass)
2. Create corresponding HS4 devices (using the new HSDevice class)
3. Delete the HS3 device
4. Change the HS4 device reference number (is this even possible?)

What are my options? What are you guys doing in your plugins with different device versions?

[w.vuyk]

In an ideal world the supplier of the software (in this case HST) would have delivered a document or description on how to do this.
Until that happens, in my plugin, I just set the devices as they would be when created new in HS4. I am certainly not breaking existing Parent Child relations as for my plugin too many different kinds of devices exist. That does not change the device version, but that part is undocumented......

As for different device version (new devices created after the initial conversion) I have not discovered any issue with that, no different code needed.

Wim

[rmasonjr]

In an ideal world the supplier of the software (in this case HST) would have delivered a document or description on how to do this.
Until that happens, in my plugin, I just set the devices as they would be when created new in HS4. I am certainly not breaking existing Parent Child relations as for my plugin too many different kinds of devices exist. That does not change the device version, but that part is undocumented......

As for different device version (new devices created after the initial conversion) I have not discovered any issue with that, no different code needed.

Wim

Yeah, it would be nice to have a class that would handle both DeviceClass and HSDevice and have a "Convert" method

I think I can do it just iterating through the HS3 devices and cranking out new HS4 devices, but the device reference Ids is what has me a little stumped.

[w.vuyk]

That is why I am not creating new devices too. Users might have to many events depending on the device references. Preparing for HS4 I have hardened my own event actions to have them device independent. Am actively promoting to use my actions instead of device actions as those wil still find the devices. If they do that, the device can be deleted and recreated without updating the events.

But at the end, it is still a workaround

[mnsandler]

I do not recommend deleting any hs3 devices in your convert process.

I converted deviceclass to either hsdevice or hsfeature.

First I referenced the hs3 device using the AbstractHsDevice class

then I set the Relationship property

dv.Relationship = ERelationship.Device
or
dv.Relationship = ERelationship.Feature

you can then reference the new devices with either hsdevice or hsfeature

you will probably need to convert existing devices to Features and create the Parent HSDevice and then link them using AssociatedDevices.Add like the following

hsfeature_dv.AssociatedDevices.Add(RootDevice.Ref)
RootDevice.AssociatedDevices.Add(hsfeature_dv.Ref)


I would recommend asking questions in the github forum - https://github.com/HomeSeer/Plugin-SDK/issues
The HST programmers respond to questions there

[alexbk66]

What I do - I keep the old root device, but create additional Ctrl device and redirect calls and status graphics from root to this Ctrl.

Which is ridiculous IMHO, but this way I don't have to change anything in my plugins code:

i.e. handler for Ctrl state change (i.e. from UI button press) is redirected back to root



And plugin changing the state of the root (in HS3) - now is redirected to the Ctrl in HS4

[alexbk66]

I end-up with duplicate DeviceString, etc, but hopefully the users understand the reasoning:

[dcorsus]

For each HS3 device (mine tend to have many children)

- I create a NEW HS4 device
- Keep the HS3 device (and reference), change the attribute to feature and make it a child of the newly created device. If this device had children, remove the association.
- For all the children I had under the old HS3 device, I set the feature attribute and associate them to the newly created device.

As such you keep all your references and you follow the HS4 guidelines.

[alexbk66]

I'm not sure why need to create a new device?

[Guest]

Here I have used this page to convert 3.2 devices to 4.0.

http://hs4iP_port:82/repl

This delete a device and transfer its ref number to another device. You have to recreate graphics etc on your own.

Maybe some of you could replicate what that page does?


what i do that worked :

Create or copy x number of virtual 4.0 devices.
With jon00 grouping utility I remove the association of these new devices. Then I use the /repl page to move the ref of the 3.2 devices to the not-associated 4.0 devices. Finally I regroup all the 4.0 devices with Jon00 grouping utility.

Result : no need to open the event page at all to change anything , all works without event modification.

[w.vuyk]

For each HS3 device (mine tend to have many children)

- I create a NEW HS4 device
- Keep the HS3 device (and reference), change the attribute to feature and make it a child of the newly created device. If this device had children, remove the association.
- For all the children I had under the old HS3 device, I set the feature attribute and associate them to the newly created device.

As such you keep all your references and you follow the HS4 guidelines.

My challenge was that the root device in HS3 for my plugin is a functional device wich can be used for events etc, so it was not an option for me.
Now realizing the steps Dirk does I wonder if I could have demoted my original root device to a child using these steps and have a new "device" root associating to it... and following your process for the childs. But again, the features/childs are still not on HS4 4.0 level, which I doubt if that is really important.
At this point I am only changing the childs to features and the original root to device.


i think you have downloaded an ASP(X) page for this? It is not standard available in HS4.

*edit* getting old, was testing on the address of my test machine wich was not running LOL. It works, but is a old internal function in HS. It would be to tricky to create a virtual device and try to get all the plugin data of the original plugin device in it. this way. And if one would do this in the plugin, is there a need as I do not see any real functional changes in the device versions

Wim

[alexbk66]

My challenge was that the root device in HS3 for my plugin is a functional device wich can be used for events etc, so it was not an option for me.
Now realizing the steps Dirk does I wonder if I could have demoted my original root device to a child using these steps and have a new "device" root associating to it... and following your process for the childs. But again, the features/childs are still not on HS4 4.0 level, which I doubt if that is really important.
At this point I am only changing the childs to features and the original root to device.

Did you see my post #6?

[rmasonjr]

I'm wondering if we should petition HST for some clear guidelines on what to do for this scenario. I think I'll open a ticket and post on github.

[dmurphy]

Good luck with that!

[rmasonjr]

Good luck with that!

hahah! I just opened the ticket - let's start a HS Timer on how long it takes! lol!