Creating New Device is “Stuck” making a Child Relationship to nonexistent Parent

[LZHenry]

ISSUE: Every time I attempt to create a new MQTT defined device, the device is created as a CHILD to a non existent Parent.

I have my HS database and my mind confused. Procedure for new device definitions working well a few days back.

JSON Decoding set to: Decode payload JSON into individual HS Devices (have also tried the second selection … Place full payload... )
Express Mode is Default accepted Topics to full support
have tried checking Decode JSON into separate HS Devices

Procedure:
Use the “a” check box to create a new HS ref ….AH! No ref shows in box and HS has a new device.
Result:
New device with...
Relationship Status = Child
Associated Devices = (Not Found=448) (448)




Hours of testing; I am stuck; please provide recommendations.

[Michael McSharry]

I do not experience a problem for the case where the Associated row is either non-JSON payload or the end point of JSON payload key. I do see potential issue when a topic that has JSON payload is Associated. The parent/child relationship has changed since the original design to operate similar to what HS4 supports where all end points need to also have a parent and the parent cannot have controls.

The JSON Decoding options on the General tab should no longer change behavior as that is now being forced to HS4-like behavior. In the screenshot below I click on the A column checkbox for row 1 and 5. Devices 694 through 697 were created. 694 and 696 are parent and they are effectively only placeholders so HS3 behaves like HS4.

[LZHenry]

I am actually glad “your” system is working correctly, because that means I have a real issue for you to think about versus me just not reading the documentation!

I suspect after all my testing my HS database is somewhat corrupt. This caused after finally properly transitioning to V13. Then I experienced some hard HS errors, (forgot to save the errors), was required to restart HS to get the device list back; then I think this current issue started.

Still, mcsMQTT “could” do something to “clean” my error?????

Right now, I can not find a way to go forward and again start creating new devices. Your are skilled and could suggest my next testing?

[Michael McSharry]

Homeseer database is in \Data with type .hsd. There are backups there so you can return to an earlier version.
The mcsMQTT database is in \Data\mcsMQTT\mcsMQTT.db and backup with same name and date stamp so you can return to earlier version there too.
You can also email mcsMQTT.db to mcsSolutions at CenturyTel do net and I can see I have any issues using your mcsMQTT database.

[LZHenry]

UPDATE 7:06 PM
FINALLY got a link between versions and the Child/Parent issue.

I do not know WHY, but know how to get this working proper and then “failing”.

Found a previous archived set of HS3 files dated earlier in May

These files had an improper attempt to manually install 5.2.4.13. I manually loaded the V13 files but had improperly left V5.1.1.7 dll files in the root HS3 directory. This is the version which showed two different versions.

• Load the 5.1.1.7... creating new MQTT devices.. SUCCESS... devices created without CHILD relationship.
• Delete 5.1.1.7 files from the root HS3 directory allowing V13 to fully load properly
• BAM!!! all MQTT device additions generate the CHILD/PARENT device pairs
• I am assuming this is now repeatable... install V7, all OK, install V13 issues arise.

Again, would like to know if this issue will return when I load future version updates. I will try more investigation tomorrow.

LZH

PREVIOUS WORK BELOW



UPDATE 6:33 PM
Just completed an unsuccessful CLEAN update... very confused still.

• Manually deleted all the mcsMQTT files
• Deleted the HS3 database file
• Boot HS3
• CONFIRM No devices, no events no MQTT Plugin
• Install & Enable MQTT V 5 2 4 9

And yet, again, I am getting the automatic generation of Child/Parent devices
and again device numbering starts not at 1 but at 471 & 472

There is something I am not deleting to get back to a clean mcsMQTT system???

Below is what I wrote earlier in the day...

I am profoundly grateful for the offer to help. Databases on the way to you soon, but probably not worth your looking based on the results below.

Loaded VERY old db files but no help yet; still creating child.

SO with great frustration...

Deleted ALL mcs db related files in mcsMQTT folder

Deleted ALL db related files in the Data folder


HS loads as expected with NO Devices, NO events..

Wait for my MQTT test message to arrive..

Select “a”

ICK!!!

The newly created device is CHILD to a newly created Parent

Select “a” for a second MQTT test message

ICK!!!

Second device is CHILD to FIRST created PARENT.

Interesting: Referencing for these devices are at 468, 469,470. I expected these to restart at 1??? Yes, I did shut off all WEB pages and restarted all for these tests.
So, still hoping for your thoughts.

LZH

[Michael McSharry]

The mechanism that HS used to assign ref numbers is not something I am privy. It is just a number so should not make any difference.

Welcome to the world of HS4. Parent devices need to exist. Even if only one child exists a parent also needs to be created. In HS4 nomenclature the parent is call a device and a child is called a feature. The parent get a tile and the feature gets an icon in the default HS4 display.

mcsMQTT considers the topic the parent and the Json keys the child. If not Json then the parent is the topic at the next higher level of indenture. In the example I provided in this thread I covered both of these cases.

I think your setup is working. Just need to need your head around the current HS(4).

[Guest]

Hi Michael, quick question:
currently on HS3; I took a habit of deleting all Parent devices as they are of no use to me and create unnecessary clutter.
If I decide to migrate to HS4, would this be a transition issue? will they be "re-created" automatically or should I expect hours of manual rework?
Thx

[Michael McSharry]

I have been holding off on releasing the HS4 version of mcsMQTT because of all the use cases that are available, testing to support them, and providing a consistent migration path. For your specific question I expect the HS4 plugin to create parent devices for the orphan children at startup. Same algorithm that is now used in HS3 plugin, but invoked at startup as well as new association.

[Guest]

Thanks Michael,
no worries, I didn't plan to migrate until concerns from main PI developers are addressed. Will keep an eye on things. Thx.

[LZHenry]

Michael... somewhat confused by the information, and still do not know how to continue testing.

I am using HS3.... you refereed to "REQUIRED Parent/Child" devices that will be created with HS4????

So far, what I do NEVER requires a Parent/Child Relationship. Are you indicating that this will this change when I install V12???

I will test later today by manually installing V12 into my "empty HS3" running test system. I anticipate AGAIN getting my inappropriate Parent/child pairs that I do not want/need. If true, I am still left with the original issue to solve.

"The mechanism that HS used to assign ref numbers ..." I provided this information because it seems to indicate that I still have a setup issue that could cure my other problems; hoping this would cue something with your experience.

Thanks LZH

[Michael McSharry]

My guidance above was to provide mcsMQTT.db via email. I had responded via email that I do not have privileges to read you google drive files.

mcsMQTT is moving toward HS4. I am trying to make the HS3 version work like the HS4 version so the transition delta is minimized. There was not one single release where Parent devices were created, but has been incremental. 123qweasd indicated that he manually deletes the parents after being created by mcsMQTT. I cannot assess the implications of doing this, but I do know from the HS3 perspective it does not matter if a parent exists or not. Newer functions, like HomeAssistant Discovery protocol, WLED, or Shelly will likely have some negative effects of manual deletion.

You thought there was some error that was not captured and then the original problem of Parent devices not existing was observed. Your thought it was a HS3 database problem so I suggested going back to an early HS3 database (.hsd). The same could be done for mcsMQTT. Start with something that worked in the past and then try to move forward deliberately. You could do the same thing on your "empty" system and installing old databases.

[LZHenry]

Michael... Finally I understand that Parent/Child is a “requirement” of going forward. Looking back, I now understand your previous example. Pardon please, you are about 142 steps ahead of people like me, and things did not sink in till now. Today I see that V13 is officially available as the latest; will update and proceed, maybe.

I am considering this item SOLVED. Item below is an observations not needing a comment.. I think.

There are 3 ways to delete a device. I assume using any of these is the same and none will cause adverse issues.

1. Uncheck the “a” box at the Association table list
2. Selecting the ref and then using “Delete Sub and Ref”
3. From the device configuration screen, using the “Delete” button

Database send via Email... Thought I enabled the permission for you to view... Think you no longer can benefit from these but I can send again if you want.

I previously confused you... Dont know what a point parameter is.
“Point” is aka “Device”... hold over from a previous life; tried to catch them all but missed this one.

LZH

[Michael McSharry]

The three scenarios produce different results. There is also a 4th & 5th method described as part of #2 below.

#1. Deletes only the HS Device. It does not do anything with the subscribed Topic.

#2. The Edit Tab "Delete Sub and Ref" and the Association Tab Obsolete column for the same topic have the same effect of removing both the Topic and the Device. If the Topic is received again then it will be created again for display on the Association Tab. The Obsolete action can also be done from the General tab, Inbound Management section, by entering the Topic in the Obsolete row text box.

#3. Deletes the HS Device just as the others, but leaves mcsMQTT thinking that the device still exists. If the Topic is received it will try to update the non-existent Device. I had considered checking to confirm HS devices are present during startup, but elected not to do it because of the startup time burden it could incur for those who have many HS Device mapped via mcsMQTT.