Announcement

Collapse
No announcement yet.

Parent - Child devices disappearing from association table.

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

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

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


  • 123qweasd
    replied
    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,

    Leave a comment:


  • Michael McSharry
    replied
    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.

    Leave a comment:


  • 123qweasd
    replied
    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.
    Click image for larger version  Name:	uyuykuyk.JPG Views:	0 Size:	36.9 KB ID:	1391821

    So the new standard is this

    Click image for larger version  Name:	wwqdwq.JPG Views:	0 Size:	35.2 KB ID:	1391820

    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?

    Click image for larger version  Name:	screenshot-192.168.0.117_8082-2020.06.06-17_37_00.png Views:	0 Size:	586.0 KB ID:	1391823

    Thanks,
    Attached Files

    Leave a comment:


  • Michael McSharry
    replied
    I took care of the post #13 issue with http://mcsSprinklers.com/mcsMQTT_5_2_9_2.zip. Control with color picker or control with sliders will result in the same publish topic & template with the three individual values of H, S and B.

    I am not understanding the expectation with #14. If a parent device is removed then the linkage information that HS uses for grouping display is lost and results in the first screenshot. The second one is as expected with a group under the RESULT topic/parent when the parent is not deleted. Perhaps you previously had the color picker as the parent and the sliders as grouped children. This scenario is no longer possible as HS4 does not allow controls on parent devices.

    Leave a comment:


  • 123qweasd
    replied
    just also noticed that under Device manager, they are displayed as separate devices, not in the same parent/child type group as usual;
    Am I forced to keep the parent device in the association table? it was not the case before.

    Click image for larger version

Name:	qwer.JPG
Views:	32
Size:	40.5 KB
ID:	1391782

    also tested while keeping parent device, still doesn't work:

    Click image for larger version

Name:	wwqdwq.JPG
Views:	31
Size:	35.2 KB
ID:	1391781
    Attached Files

    Leave a comment:


  • 123qweasd
    replied
    Hi Michael, it seems a small bug was introduced in 5.9.2.1 or maybe I am missing something:

    The HSB color picker publishes but the 3 child/sliders (HSBcolor 1, 2, 3) don't publish;

    They do adjust in HS when parent/HSBcolor is modified but can't seem to publish on their own.

    Is something disabled or is this a bug ? Let me know, thanks!

    Leave a comment:


  • 123qweasd
    replied
    No worries, thanks Micheal.

    Leave a comment:


  • Michael McSharry
    replied
    It seems there are several light variants with only Tasmota and then other firmware providers as well. I can understand doing things in the plugin to be able to user HS color picker or a specific family such as Shelly or WLED. In this case it seems all the tools are in place for a natural integration so I think I will pass on the CCT light.

    Leave a comment:


  • 123qweasd
    replied
    Ok. All working good now; Thx Michael;

    One last thing, not a big deal but I've noticed that you adapted some sliders to the actual function : IE: Hue 1-360, etc.
    Did you consider adding CT - 153-500 (https://tasmota.github.io/docs/Lights/)
    I currently do it manually, not a big effort but could be nice to have it preconfigured.

    Thx again, cheers!

    Leave a comment:


  • Michael McSharry
    replied
    I suggest from the Association tab, uncheck the A column checkbox for the HSBColor topic and let the plugin create a new one. Go to edit tab to change type to HSB. If there are leftovers in HS then manually remove them.

    My internet connection is problematic with upload speeds measured in bit/sec and not kilo or mega units. It takes awhile and hope it does not abort.

    Leave a comment:


  • 123qweasd
    replied
    edit: hold on.... for some reason, I had version 5.2.1.9 instead of 5.9.2.1...
    will test in a second

    Leave a comment:


  • 123qweasd
    replied
    Same behavior

    I tested without deleting the parent device, rebooted HS3, now I have 2 associations without an edit menu or payload.

    Click image for larger version

Name:	1111111111111111111111111.jpg
Views:	52
Size:	23.8 KB
ID:	1390946Click image for larger version

Name:	222222222222222222.jpg
Views:	45
Size:	60.3 KB
ID:	1390947

    Leave a comment:


  • 123qweasd
    replied
    Hi Michael, the file/link is corrupted, can you reupload? Thx

    edit: works now thx

    Leave a comment:

Working...
X