How to - device with buttons (or other) WITHOUT making second device

[JamesWestoby]

Ok, been plowing through the Samples (all of them) and nicked the code for the Camera/Sample plugin to make a device.

Problem is I want the buttons (or list or radio or whatever) >ON< the base device (see the list view of the devices) - not as an associated device* with its own DevRef.

HomeSeer CAN do this, the virtual device allows putting the buttons ON the device, the picture shows it better -



The TestDeviceXY is the inbuild Virtual device and the buttons on there are WITH the device, but my device Kettel has an additional (unwanted) line/dev for the controls.

It all works (I get the associated/parent device) but it is silly!

*Funnily enough I WILL be using parent/chold devices later when I port my Velleman K8055 plugin device over - but that is another day.....

As I see it the problem is the DeviceFactory. CreateDevice and the later HomeSeerSystem.CreateDevice - but how do I get rid of one of them please?

As ever, thank you in advance and thank you for reading.

[alexbk66]

That's HST policy - not having controls on Root device. I'm trying to get explanation WHY? From rjh for years - the answer is "just because".
I don't get why I need two devices for a simple On/Off switch?

[racerfern]

rjh replied to one of my posts many years ago that HS was planning on doing away with root devices. I made the post because a gocontrol outlet I just included didn't have a root. See attached. That was at least 2-3 years ago but since then it continues. Meanwhile I have two or three devices that do not show a root and I wish they were all like that.

[JamesWestoby]

Oh so thank you both - I'm NOT going mad!

My comment?

Doesn't seem like it has any rationale behind it, and if all you get is 'just because' then I'd have to say it's probably laziness (poke!).

[alexbk66]

Rich says that even status on root is not welcome, drives me mad. I get that I can "stop thinking about a device made up as multiple devices" - but instead of 500 useful devices I have 1000 - and half of them are useless.

Our goal with HS4 was that the root device is just a descriptive device, so in some UI's it will not have the space to display any status (like HSMobile). This is not an issue though as we will soon allow you to specify a primary feature device to display in the UI. We currently automatically pick one.

https://forums.homeseer.com/forum/de...-have-a-status

again, the root is just for the name, it will not say "no status" next to it. You only see that because its an HS3 device. Devices now have a version property and HS3 devices are set as version 3.2 and HS4 as 4.0. We use this to alter the display. If the device was an HS4 device you would not see any status.

I would stop thinking about a device made up as multiple devices. HS3 called them that and they were all created like devices, but the new SDK abstracts that for you so you don't need to deal with a root device. You create a device and add features to it. If you don't look under the hood (or the HS3 devices page), you would not even know it was 2 devices.

[happnatious1]

I was working with my monoprice amp plugin last weekend and couldn't get HS4 to stop building duplicate devices. After I went to HS4-->setup-->labs "fix Device/feature relationships" everything looked OK again.

I'm honestly not sure how to properly build a device anymore that will be proper in list view let alone grid view.

[JamesWestoby]

Got to say not being consistent, here's (on my dev/test system - BEFORE I DARE attempt to upgrade my HS3) HomeSeer's OWN Z-Wave plugin and a TKB Switch I just added -

No additional lines.....

[JamesWestoby]

Also just for funsies I added a spare and >>>USB powered<<< Fibaro eyeball to HS4 - the primary device is BATTERY!

How useful is that>

Chances are I would want the motion detection as the primary device.

(In grid view it has the battery icon and in the popup list of features the battery is missing, anyone care to explain the logic in that?).

[Rick Tinker]

Yes, the original form of a device was as a single device, and there are plenty of Z-Wave devices out there that still only have single functionality and thus do not have the root/child structure.

I have no idea why Rich is talking about getting rid of the root device because IMHO when I invented it, it was what allowed HomeSeer to support virtually ANY Z-Wave device because unlike other controllers, it did not have to render a UI for every possible combination of device functionalities. That is what prevented other controllers from supporting new devices quickly. I can definitely see where it is possible though to take the spirit of multiple devices and just eliminate the root device, and that would be fine, but without something to link the child devices together I think it would have a high potential for chaos.

I am assuming that they did something in HS4 to prevent the root from having buttons/functionality as a first step. I guess you can call that progress. ;-)

[alexbk66]

I'm honestly not sure how to properly build a device anymore that will be proper in list view let alone grid view.

I opened a ticket in GitHub, but feels like just talknig to myself...

https://github.com/HomeSeer/Plugin-SDK/issues/137

[SteveMSJ]

I have no idea why Rich is talking about getting rid of the root device because IMHO when I invented it, it was what allowed HomeSeer to support virtually ANY Z-Wave device because unlike other controllers, it did not have to render a UI for every possible combination of device functionalities. That is what prevented other controllers from supporting new devices quickly. I can definitely see where it is possible though to take the spirit of multiple devices and just eliminate the root device, and that would be fine, but without something to link the child devices together I think it would have a high potential for chaos.

I am assuming that they did something in HS4 to prevent the root from having buttons/functionality as a first step. I guess you can call that progress. ;-)

I don't think there has been any suggestion by HST of getting rid of the root device, in fact the HS4 intent is that every device should have a root device even virtual devices. My understanding is that the change is that the root device shouldn't have any controls or status, which should all be on the features (child devices).

There are shortcomings in the GUI which means that this methodology doesn't yet display well. That really should have been sorted at HS4 alpha stage, IMHO, but it is what it is and I think I understand the intent and the purpose. Maintaining backward compatibility with HS3 makes it all look muddled but is necessary.

When an HS4 version of the ZWave pi is finally available it will presumably convert those single devices, such as the TKB switch mentioned earlier, to a root with one feature (child). We were expecting HST to show the way with the ZWave pi conversion as an aid to other pi authors but many months later, still no sign. Some brave authors have forged ahead with converting their plugins and have presumably followed this philosophy.

Just my 2p,
Steve

[alexbk66]

Some brave authors have forged ahead with converting their plugins and have presumably followed this philosophy.

Yes, I had to de-compile their Scheduler.dll and Z-Wave plugin to find out how it's supposed to work. And that totally sucks - developers are supposed to get support from HST - this is part of legal agreement https://homeseer.com/3rd-party-devel...bution-policy/



But there's next to zero support. And the current state of PluginSDK and the documentation is also very frustrating - especially given that HS4 is in development for more than two years.

[alexbk66]

Oh, yeah, regarding "root device" - I still think the way it's implemented - is very limiting and even stupid. Why hard limit to only one level of parent - child? And make parent completely useless at the same time? Why not support normal parent - child - grandchild - etc.?

[popeye]

That limitation bugged me the first time I ran into it. I come from an archaic home control system (Premise Systems - way, way dead and not supported) that ends up having much more in the way of being object oriented and straightforward features. Everything is an object, and everything can be modified on the fly. All tree oriented, so a device description can contain as many child levels as needed, and each node can contain any type of properties you want to define. Events are treated all the same, rather than having a separate RegisterStatusChangeCB thing, and can easily be filtered based on a node in the tree. Lots of enumeration API's that can filter based on properties and property values and so forth. Separation between objects representing physical h/w and the virtual representation in a house/building/property, plus automatic matching of properties between the two, so underlying h/w can be swapped out without having to mess with the virtual representation and associated events/scripts. Completely h/w agnostic.

Anyway, all this to state that HST has a long way to go to catch up to a product that came out about 20 years ago, and hopefully they can get there faster by focusing on the right things, like fixing their Z-Wave plug-in to depend on device config files, rather than making people wait (for years sometimes) for device support. They could probably due with a good Program Manager to determine the best path forward.

Done venting.

[Rick Tinker]

That limitation bugged me the first time I ran into it. I come from an archaic home control system (Premise Systems - way, way dead and not supported)

Holy cow - I never thought I would meet a Jim Hunter fan. See if you can find my review in a home automation magazine about his first product, MASS... LOL

Anyway, all this to state that HST has a long way to go to catch up to a product that came out about 20 years ago, and hopefully they can get there faster by focusing on the right things, like fixing their Z-Wave plug-in to depend on device config files, rather than making people wait (for years sometimes) for device support. They could probably due with a good Program Manager to determine the best path forward.

Gotta respectfully disagree with you on that one. There are many things that plug-in needs to get updated, but device support is absolutely the best out there. HomeSeer created the root/child relationship specifically for the Z-Wave plug-in so that no matter what combination of Z-Wave command classes were in a device, HomeSeer could handle it. If there is a device that is not supported by HomeSeer, I am very surprised and suspect it is more about how old the plug-in is than it is about how it supports device technologies. For 12-13 years HomeSeer has been used by device manufacturers to test their devices BECAUSE they cannot get other hubs to support a pre-production product.