Parent - Child devices disappearing from association table.

[Guest]

Thank you Michael, it works now.

just so I am clear on things : my HSB devices are currently configured as below which is no longer working;
this is essientially the " color picker as the parent and the sliders as grouped children" . Correct ?
and this wouldn't be compatible with HS4.


So the new standard is this



which is a "group under the xxxxx topic/parent " And I must keep the parent (3511) ;

Other than keeping parent/children in sync, It's essentially just a "placeholder/nametag", right?
I also can't build on my current HSB devices which must be deleted and created fresh, correct? no big deal but just want to make sure I'm not generating extra work if not needed.

Since mcsMQTT started creating parent devices, I deleted all of them without impact since they didn't have any known dependancies/children. Except for HSB.
Would this be an issue when I upgrade to HS4? will the parent devices be "re-enabled" automatically or will I have to delete all devices and start over?
Can I "re-enable" the parent devices now in HS3 if needed?

Last question, for the scenario below; could I safely delete 2484/2631 or do they act as Parent for all "message:id" and "message:unit" topics (lower in screenshot)?
At one point I remember having to click the "Check to treat JSON key" checkbox to parse the data which no longer seem to be the case, so I assume you have "automated" the parsing for such devices?



Thanks,

[Michael McSharry]

For the HSB devices the logic goes like this:
mcsMQTT maintains MQTT info about RESULT:HSBColor and creates 4 HS devices. The color picker device PED contains the device reference to the H, S and B devices.
When HS commands a H, S or B device there is no MQTT info available for these so mcsMQTT needs to find the MQTT info which it does by finding the parent device and then looking for the color picker child. This means that the parent device must exist.
I am in the middle to testing the HS4 plugin in this area for CSV and see an easier way to handle this is to put the color picker device reference or CSV item in the PED of the H, S, B or CSV devices. If I do only this it is a breaking change since previously created H, S, B and CSV will not have the necessary pointers. What it will do, however, is remove the need to have the parent device present to perform the search. If the parent device is deleted then HS will still not be able to group the four HSB-related devices. If I maintain backward compatibilty then the parent device needs to remain. If I break it then the parent is optional for HS3.

For the HS4 upgrade there is currently no logic to validate the HS3 install for compatibility. I suspect what will be done is to create parents for any HS3 device that has a control. Assuming this path is taken then if you delete the HS3 RESULT parent device then when HS4 plugin sees HSBColor device with a color picker it will create a parent. What could be problematic is what happens with the H, S and B devices as they could also get individual parents to maintain HS4 compatibility. If it was only HSB that was considered then logic should be able to be developed to reconstruct as desired, but MQTT is very generic so a generic solution may not provide the desired result.

HS3/4 owns the device reference numbers so a plugin cannot assign them. It can only get the next available one from HS. The undelete parent capability has the same problem of the generic conversion from HS3 to HS4 as described in the prior paragraph.

For the nested JSON data I am a little surprised you can now map HS devices to both a summary JSON level and the individual keys. In the past this may have been possible (and it still may be). While things are not solid, I consider summary levels to be parents and with the HS4 rules parents cannot have controls or show status. This means they would not have the ability to edit MQTT parameters. To answer your specific question, there are no relationships within the HS3 plugin that relate 2484/2631 to anything so their removal should have no negative impact. Obviously this is an area that has not had too much consideration.

I have removed the option of how incoming data should be parsed. If the payload data is JSON it gets decoded into individual items. Summary level items no longer get the DeviceString populated. It could be that only Topic level information is considered as a parent so all JSON items would have the same parent.

[Guest]

Thanks Michael,

since recreating devices and all associations in HStouch is a long and painful task, what would be your recommendation regarding creating and configuring MQTT devices/parent/children/topics?

Especially for HSB and parsed "message:id" and "message:unit" topics mentioned above (these last two will have a ton of sensors associated so I really don't want to start over again.

Let me know what would be the best approach to ensure I don't have to redo everything once I decide to migrate to HS4.

PS: if keeping the parent device makes things easier for you and the future HS4 integration, I have no problem keeping it.
Just let me know if this should be the way to go and also If I should recreate topics/devices where I deleted the parent (STATUS and RESULT for instance)

Thanks much,

[Michael McSharry]

Your transition to HS4 will be cleaner if you leave newly created parents. At this point I would not recreate the parent relationships as the transition to HS4 is not real solid at this point so don't want you to have to do something twice.

I have been doing all my work on HS4 for both HS3 and HS4 plugins. I tried once to take a HS3 install and update, but had problems doing it. Others have provided guidance that a clone is needed so iterations of the transition are awkward and slow. My intention is to make is as easy as possible for the end user so I would not expect there to be a big rework effort for you.

[Guest]

Thank you Michael, Will follow your advice and circle back when Im ready for the HS4 transition.