Migrate HS3 documentation

[dcorsus]

If the functionality of the device is not changing, you really don't need to migrate it. Is there a reason you want to do this?

Confused .....

I thought devices couldn’t have controls and we had to create features, no?

[randy]

Confused .....

I thought devices couldn’t have controls and we had to create features, no?

The way I understand it is that in HS3 we had root devices with children. In HS4 the device root is now the parent or container for all the child devices which are now called features. That is exactly how HS3 devices import to HS4. A standalone device like a virtual or older Z-Wave switch is just represented as a device with a control, no "features".

Here is one of your Sonos players imported from HS3



Note that none of the Features are shown. This something Rich is going to need to help figure out, because all the features are there



A single device with no child devices just shows its control and has no Features

[mnsandler]

Rich,

its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

i don't need an answer to any of this here.

Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

the entire devicefactory, and all its related objects needs a lot of documentation

for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.

[kriz83]

If the functionality of the device is not changing, you really don't need to migrate it. Is there a reason you want to do this?

Why mark the plugin than as a legacy plugin?

Verstuurd vanaf mijn SM-G965F met Tapatalk

[rjh]

I was referring to migrating HS3 devices to your HS4 plugin. These are devices that the user already has created.

Why mark the plugin than as a legacy plugin?

Verstuurd vanaf mijn SM-G965F met Tapatalk

[rjh]

HS4 allows HS3 devices to work as they did before, so no issue there. But in HS4 the root device cannot have controls on it. So add features (child) devices to your root and put your controls on those devices. If you don't have any controls on your root devices then your child devices can look the same in HS4 as they did in HS3. If you have a specific question on how to create your devices I can get an answer for you and post some sample code. The sample plugin has code that creates devices with features. Remember that a "device" is a root device and a "feature" is just a child device.

Rich,

its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

i don't need an answer to any of this here.

Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

the entire devicefactory, and all its related objects needs a lot of documentation

for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.

[rjh]

IIn regards to multi-instance plugins, there really isn't a need for it as you can implement this easily in your plugin. Just put all your logic in one class and then initialize that for each instance you need. We felt it was far less confusing to the user to do it this way.

There is one issue we are aware of. Some plugins need to run remotely on different computers. So in this case we do need a way to support the same plugin running multiple times. We are working on supporting that.

Rich,

its not clear how hs4 devices and features map back to existing hs3 devices. I read somewhere that we can't have 'controls' on a device; now that they must be on features.

i am taking the approach of rewriting my vista alarm plugin in native hs4 code; I don't know what a new hs4 device is going to look like; hence my concern about hs3 to hs4 device migration. will an hs3 migrated device behave/look the same as an hs4 created device.

i don't need an answer to any of this here.

Basically, we need more sample code and write ups in the *SDK* (https://docs.homeseer.com/display/HSPI/Overview). You have been working with your new hs4 architecture and object model for months if not years; the rest of us (who are not full time programmers) need good quality documentation to get up to speed); spending our time on trial and error, wading through this forum, and waiting for answers is painful, frustrating, and time consuming. I hope you will make this a priority.

the entire devicefactory, and all its related objects needs a lot of documentation

for example, why were multiple instances dropped; do you have a recommendation or alternative solution? this would be valuable info in the SDK. just saying its depreciated doesn't help. a lot of us spent a lot of time in hs3 on this feature.

[mnsandler]

HS4 allows HS3 devices to work as they did before, so no issue there. But in HS4 the root device cannot have controls on it. So add features (child) devices to your root and put your controls on those devices. If you don't have any controls on your root devices then your child devices can look the same in HS4 as they did in HS3. If you have a specific question on how to create your devices I can get an answer for you and post some sample code. The sample plugin has code that creates devices with features. Remember that a "device" is a root device and a "feature" is just a child device.

Rich,
in my HS3 insteon plugin, i used parent/child relationships (both parents & child devices could have both controls, and status), and i kept track of the number of hs devices. for example, a KPL is 8 devices (1 parent, 7 child)

Now in HS4, if i create a KPL device, the device architecture is different. For example, a new KPL is 1 root, and 8 features (i guess) for a total of 9 devices.

so there is no consistency between hs devices (ie what they represent), and how i would manage them in my code

when the plugin receives a message from a device, it knows which button sent the message (1..8)

it would seem i would need code to manage hs3 legacy device differently than hs4 native devices.

[dcorsus]

Rich,
in my HS3 insteon plugin, i used parent/child relationships (both parents & child devices could have both controls, and status), and i kept track of the number of hs devices. for example, a KPL is 8 devices (1 parent, 7 child)

Now in HS4, if i create a KPL device, the device architecture is different. For example, a new KPL is 1 root, and 8 features (i guess) for a total of 9 devices.

so there is no consistency between hs devices (ie what they represent), and how i would manage them in my code

when the plugin receives a message from a device, it knows which button sent the message (1..8)

it would seem i would need code to manage hs3 legacy device differently than hs4 native devices.

This is an excellent example Mark, I ended up pretty much in the same way. I have written my HS4 version, so I made all that work, the key problem for me is how to support people who came from HS3, who spent a lot of effort setting up HStouch screens, events, automation, scripts etc. and elect to use my HS4 plugin so they can make proper use of all the new functions enabled in HS4 (example there is a player optimized tile view).

In HS3 one Sonos player was a root device with controls and about 19 children, so 20 devices in total. In HS4, that code turned into one root device and 20 feature devices. I know I could write some conversion tool BUT the major issues is that I end up with different HS references after conversion which subsequently will break events. So I'm also eager to get guidance how we could address this, also curious how the HS3 to HS4 DB conversion tool works. Maybe it doesn't do any of this assuming all devices that were created in HS3 will remain exactly the same.

Last but not least, even though features are just like devices, I seem to recall that there are attributes associated which define them as devices over features and you cannot use say an HS function like getdevicebyreference on a feature and visa-versa. So Rich your statement that they are all "devices" even though called features, not sure that is 100% correct.

Thanks for giving guidance,

Dirk

[alexbk66]

But in HS4 the root device cannot have controls on it.

Just wondering why? What's the reason? I always tried to minimise number of HS devices by putting controls into root.

For me it's just redicoulus to have an extra device which just sits there saying "No status"

And the main reason I try to minimise number of HS devices - is because HS doesn't provide a user friendly way of selecting a device in events / HSTouch designer, etc.

So the users have to scroll the list of 1000 devices

If you force developers to multiply the number of devices - please also implement descent device selection!

[mnsandler]

Just wondering why? What's the reason? I always tried to minimise number of HS devices by putting controls into root.

For me it's just redicoulus to have an extra device which just sits there saying "No status"

And the main reason I try to minimise number of HS devices - is because HS doesn't provide a user friendly way of selecting a device in events / HSTouch designer, etc.

So the users have to scroll the list of 1000 devices

If you force developers to multiply the number of devices - please also implement descent device selection!

I do know the bogus root device has something to do with the UI, this all started with the homeseer app in HS3. HST didn't want to support controls/status on the root device but too many of us already had that in place. so HST supported it in the app.

I guess in HS4 they are putting their foot down. still doesn't make sense; it must just be for ease/consistency.

but i'm with you; its worthless.

[alexbk66]

I do know the bogus root device has something to do with the UI, this all started with the homeseer app in HS3. HST didn't want to support controls/status on the root device but too many of us already had that in place. so HST supported it in the app.

I guess in HS4 they are putting their foot down. still doesn't make sense; it must just be for ease/consistency.

but i'm with you; its worthless.

I don't mind if, but if HST could handle large number of devices, i.e. have efficient and fast enumeration (BSobel reported up to 60 seconds!) and user friendly device selection, instead of scrolling the list of 1000 devices - like I do in my AKSmartDevice - you can select Room or Group or Both or None - completely user friendly: