Creating devices, parrent, childs

[enigmatheatre]

It is the HS3 version. Greig has not completed an HS4 version, though he is close. The HS3 version is working fine under HS4, though I have not tried to add a board. I’m home from work in a few hours. I will test it.

Other than the pin 3 error you got and a problem with the colour picker I see this as a working version.

rjh Please can you send me a HS4 licence code for my Arduino plugin as I have sent multiple emails over the last month but not recieved a reply and as my trial has expired it makes it tricky to test and develop it further.

Sorry if this derailed this thread a little.

Greig.

Sent from my SM-G973F using Tapatalk

[randy]

Is that the HS3 or HS4 plugin (can't get the HS4 version to work, doesn't continue when i try to add a board in step 1).

Having that many sensors will overload the header where the features are placed, so lots of them fall out of the view. Maybe that is OK, i don't know. But how about the 'main' feature then?

I have to apologize, I forgot Greig had a beta of the HS4 plug-in in the store. That said, the screenshot I posted above was from HSMobile connected to HS3. It was just for illustrative purposes with regard to how an Arduino board looks with regard to parent/feature arrangement.

I just fired up my HS4 test system and installed the Arduino HS4 beta plug-in. I had tested the beta late last year and confirmed it was working. I just added a new board under the current beta without issue. Hopefully I will be able to spend more time with it this weekend.

[rjh]

I will discuss this internally tomorrow and get some suggestions. I understand that if you use all features, only one of those features will be controllable directly on the grid view (mobile). Users will need to click the header to bring up the feature list, then pick a feature. Less than ideal. The only way around this is to make each feature its own device. Which might be ok, you can then put them in a specific location. If each feature controls a device, this is no worse than creating a single device for each Z-Wave device. I'll post back with some options. Do you have a link to the hardware you are controlling?

It's actually a bit more complicated. You can have e.g. 2 lights, so there would be 4 buttons (2x on, 2xoff) with 2 sliders (brightness). If your board also controls there garage, then tilt/position/state are also added.

I have a hard time to decide which route i should take here.

Comparing it with the network switch. If you add 24 features, not all will be displayed in the tile overview.

[kriz83]

Do you have a link to the hardware you are controlling?

For example this: https://forums.homeseer.com/forum/li...-projects-here

This would create following features:
- distance sensor
- switch (for manually controlling the relay)
- 2 on/off sensors for the reed contacts to detect the position of the door
- a garage door: open/stop/close buttons

In the future that same board will also control the RGBWW strip, so these features are added too:
- light on/off
- color
- brightness
- light effect dropdown
- white tone

Appreciate the feedback!





Verstuurd vanaf mijn SM-G965F met Tapatalk

[kriz83]

I will discuss this internally tomorrow and get some suggestions. I understand that if you use all features, only one of those features will be controllable directly on the grid view (mobile). Users will need to click the header to bring up the feature list, then pick a feature. Less than ideal. The only way around this is to make each feature its own device. Which might be ok, you can then put them in a specific location. If each feature controls a device, this is no worse than creating a single device for each Z-Wave device. I'll post back with some options. Do you have a link to the hardware you are controlling?

rjh
, did you have a chance to discuss this internally ?
Am I the only developer who's struggling with how to organize his multitude of devices ? :-)

[rjh]

This should be one device and a feature for each input and output. Its not a network type device so its not controlling other devices and other devices are not added to it.

For example this: https://forums.homeseer.com/forum/li...-projects-here

This would create following features:
- distance sensor
- switch (for manually controlling the relay)
- 2 on/off sensors for the reed contacts to detect the position of the door
- a garage door: open/stop/close buttons

In the future that same board will also control the RGBWW strip, so these features are added too:
- light on/off
- color
- brightness
- light effect dropdown
- white tone

Appreciate the feedback!





Verstuurd vanaf mijn SM-G965F met Tapatalk

[rjh]

I will note that we are looking at ways to make the grid view easier to use when a device has many features, so that should get better. Users can always use the list view, then all the controls are up front.

[Michael McSharry]

With the two I have done it seemed straightforward for me. Hubitat organizes its end points similar to what HS4 has done with a device and a set of capabilities. For mcsMQTT my device is the Topic and each item in the payload is a feature. I have not tried to tackle mcsSprinklers and it may require some thought. It has more that 100 status devices so the easy way is one device and 100+ features, but that is somewhat useless to the end user. Some status relates to valve state, some relates to weather, some relate to time. A possibility is to slice and dice into logical devices, but whatever I choose will be a compromise and not what some user will want.

For a user who wants to organize by logical rather than device relationships I would expect the Floor and Room attributes to be used. How HS4 presents the logical relationships should go back to philosophical basis and once that philosophy is established then stick with it to avoid confusion.

I see four options. One is where the feature is the determining attribute so if a Room is Kitchen then all HS devices that have a feature with Room set to Kitchen would be presented together. This means that a tile would be replicated if the device has features in multiple rooms.

The second is the tile shows only the features that have a Room of Kitchen. This means that the same device will be replicated but will have different tile content This may have an advantage of reducing the number of clicks needed to action a control.

The third is that a device only shows once with all its features and it shows up in the Room where it happens to sort first. This could be confusing to the use as devices will tend to move around but has the advantage of not having any tile replication.

The fourth is to decouple the feature from the device so in essence each tile would be a feature rather than a device. This in effect flips the device/feature relationship when presenting to the user.

[kriz83]

will the user be able to 'ungroup' and 'regroup' himself later on, to get the optimal layout ?

[kriz83]

Also: what is exported to e.g. Google Assistant. Is it the device, 1 feature or multiple features?

Verstuurd vanaf mijn SM-G965F met Tapatalk

[pcp]

I am struggling with this as well, i.e how do I need to reorganize the existing HS3 devices for H4 (some require updates to plugins).

I have devices such as Insteon keypads or i/o boards with multiple digital and analog inputs & digital outputs wired to sensors around the house where each child feature location1/2 (floor / room above but I call them room / function) is different in HS3 to slice/dice them logically (including on the device web page). I could not find a way to do that in HS4 (different location 1/2 for Features and only show some based on filters in the UI). Some have multiple Features. The new Category is nice and better than the HS3 Device Type. In HS4 if we could slide / dice (settings and in all views) all Devices and Features by Location 1, Location 2, and Category that might help.

It is also not clear to me if a HS4 Device can have controls and status information or should be dummy root with controls and status only on child feature devices. Currently I have both (from HS3) but some do not present well (cannot pick primary feature device, relevant quick information across multiple features requiring extra clicks) and usability in to access controls in grid view. Any plans to add an “expression language” in tile view to build custom condensed content from multiple features, for example “[temperature] / [humidity]” and pick the controls across all Features that would be displayed in title view?

[mnsandler]

rjh are you going to post some sample code (including VB) to the SDK pages?

https://docs.homeseer.com/display/HSPI/Overview

we need more written documentation in the SDK. Wading through this forum is not a viable option

[shill]

rjh are you going to post some sample code (including VB) to the SDK pages?

https://docs.homeseer.com/display/HSPI/Overview

we need more written documentation in the SDK. Wading through this forum is not a viable option

And by "documentation", we mean more WORDS, not just a table of parameters.

[kriz83]

And by "documentation", we mean more WORDS, not just a table of parameters.

That has been promised for months. Same with setting the primary feature.
I wonder what the impact on the general HS4 timeline is with this enormous amount of feedback and bugs ...