Association change somehow deleted virtual device parent

[Slab0]

HI,

I'm endeavoring to upgrade my HomeSeer configuration after running an ancient configuration for many years (mcsMQTT was at 3.4.5.2 🤨... if it ain't broke, don't fix it!). Anyway, I managed to get things mostly working, with one small issue. I couldn't get a virtual device<-->mcsMQTT association to create log entries in the the HomeSeer log when toggled on/off, and while playing with the association configuration in mcsMQTT settings a bit, the parent device somehow managed to get deleted.

Running the latest HomeSeer version (4.2.11), I created a virtual device which (unlike with version 3.xx of HomeSeer) created a 'feature' device as well. Parent device had an ID of 29, feature device (named 'Control' by default) had an ID of 30. I set up an association in mcsMQTT, using the feature device (30) as the ID. When toggling the virtual device via the HomeSeer GUI, the event would get logged as expected. When mcsMQTT toggled the virtual device however, no log entry appeared. The device itself toggled just fine, just no log entry. I did toggle the 'HS Event Trigger' log entry in the mcsMQTT settings of course, and also toggled the feature (and) parent device 'Last Change Time Updates on Status Change Only' entry in the HomeSeer device configuration settings in various combinations but to no avail.

I believe that the last setting that I togged in the mcsMQTT association was the 'Value Change Event' setting, and I believe that is what made the virtual device disappear from the HomeSeer Devices page. The feature device 'Control' (again ID 30) apparently is still in the system, as evidenced by the following log entries that appears every time I restart HomeSeer:

4/19/2022 9:23:20 PM  
HomeSeer
Warning
Device (30) House All Rooms Control references a parent, but the parent does not exist


4/19/2022 9:23:20 PM
HomeSeer
Warning
Issue checking child device (30) House All Rooms Control

I was able to re-create a new virtual device using the same name/location in hopes that would take care of the orphaned 'feature' device, but not surprisingly that didn't work. It created a new device with new parent/feature IDs.

With that, does anyone know how to delete a 'feature' device with no parent? And assuming I can get that fixed, any advice on getting log entries with virtual devices toggled by mcsMQTT?

Thanks much.

[Michael McSharry]

There are some different things discussed here. HS4 does not allow a Feature without a Parent Device. This means your orphaned Feature does have a parent, but probably in a different Floor or Room so it is not obvious.

There have been some recent changes to better support virtual devices. The delta is available at https://forums.homeseer.com/forum/hs...ge-log-hs4-hs3 as the zipped dll which gets unzipped into \bin\mcsMQTT subfolder of HS. I also submitted this 5.24.0.8 version to the Updater so I expect it to be available later this week.

The support for writing to the HS log is something I have not looked at for some time, but in general the plugin is oriented toward MQTT Topics. It would be best to start with a MQTT Topic and let mcsMQTT create the Feature & Parent rather than manually creating a virtual device. This way you have full control of the devices & feature using the Edit tab of the MQTT Page.

[Slab0]

There are some different things discussed here. HS4 does not allow a Feature without a Parent Device. This means your orphaned Feature does have a parent, but probably in a different Floor or Room so it is not obvious.

I am aware that HomeSeer doesn't allow a feature device without a parent, and indeed if using the HomeSeer interface to delete either, it is required to delete both. The parent device no longer exists, the feature device does. That is because it wasn't deleted via the HomeSeer interface, it was (apparently) deleted via a mcsMQTT configuration change as described in my initial post. I won't post the device json file file here, but I would be happy to send it to you directly to confirm (HomeSeer files aren't formatted json, they are just one long json string... I created a formatted iteration so it's easy to confirm). I thought that I could just delete the json object representing the feature device (ID=30), but the resulting file generates errors on startup. I'm still looking into it.

There have been some recent changes to better support virtual devices. The delta is available at https://forums.homeseer.com/forum/hs...ge-log-hs4-hs3 as the zipped dll which gets unzipped into \bin\mcsMQTT subfolder of HS. I also submitted this 5.24.0.8 version to the Updater so I expect it to be available later this week.

I'll give that a try.

The support for writing to the HS log is something I have not looked at for some time, but in general the plugin is oriented toward MQTT Topics. It would be best to start with a MQTT Topic and let mcsMQTT create the Feature & Parent rather than manually creating a virtual device. This way you have full control of the devices & feature using the Edit tab of the MQTT Page.

In this case the, the virtual device is used for a myriad of functions and tied to a numerous events. The MQTT linkage is secondary. I would think that the plugin would treat physical z-wave devices (which work perfectly fine with mcsMQTT in the new HomeSeer setup, with all z-wave toggles logged appropriately) and virtual devices the same with respect to logging. Indeed, if it's just a CAPI Control Handler call, I don't understand why HomeSeer just doesn't log it

[Michael McSharry]

mcsMQTT only deletes Device and Features of the devices that it created (unless there is a bug).

Virtual devices do not use the CAPI interface. Only plugin devices use it. That is why control of a Zwave (or mcsMQTT) will have a different logic path than the virtual device.

[Michael McSharry]

From the mcsMQTT user manual. As mentioned earlier this is not something I have looked at in a long time.


How to record changes to HS Log

When a device is controlled from the HS UI then a “Device Control” action is put in the HS Log. If a similar logging is desired when the device is updated based upon MQTT payloads then two setup actions are needed. First is on the History tab using the Pub-Sub Message History checkbox to Log changes. The second is on the Association Tab H column to checkbox the specific topics for which logging will be done. When the log entry is made one of two forms will be used.

[Slab0]

mcsMQTT only deletes Device and Features of the devices that it created (unless there is a bug).

Virtual devices do not use the CAPI interface. Only plugin devices use it. That is why control of a Zwave (or mcsMQTT) will have a different logic path than the virtual device.

I only posted because I think there may be a bug. I can say with 100% certainty that I didn't delete the parent device device, and as we both agree I couldn't delete only it even if I wanted to via the HomeSeer GUI.

Re. virtual devices and CAPI, I'm curious why this is logged when I toggle the virtual device ('Security System' is the parent of the virtual device, 'Control' the feature) on the HomeSeer Devices tab:

Device: House All Rooms Security System Control to Off (0) by/from: CAPI Control Handler

[Michael McSharry]

Look at the Interface property (Advanced tab) for the Device and Feature. /deviceutility gives you more information than the HS4 devices page.

When regrouping from the mcsMQTT Edit tab and a Feature has been moved then it is possible that a Device is deleted if it has no remaining Features. If the problem you experienced still exists with the current plugin version then we can investigate it.

[Slab0]

A couple of updates:

If I check the "h" box on the Associations tab and "Log changes In topics marked With H checkbox On Association tab" under the "History for Near Term Analysis (SQLite DB)" section on the History tab in mcsMQTT, a log entry is generated (by mcsMQTT) when the virtual device is toggled:

Device 32(House All Rooms Control) Changed from 100 to 0

As previously mentioned, when toggling the virtual device via the HomeSeer interface a HomeSeer/CAPI log entry is generated:

Device: House All Rooms Security System Control to On (100) by/from: CAPI Control Handler

Observations/comments:

- I find it a bit confusing that the "Log changes In topics marked With H checkbox On Association tab" option is under the SQLite DB configuration, since the actual mcsMQTT.db file doesn't actually appear to be updated (I'm guessing that's because the "Days of History Retention" setting was left to 0). It would seem a bit more logical (to me) if the retention aspect was separate and distinct from the logging aspect.

- I'm also still a bit confused as to why HomeSeer logs a CAPI Control Handler entry when toggling a virtual device if it indeed isn't actually handled by CAPI.

Differences between the mcsMQTT 3.x version and the 5.x version:

- All logging was handled by HomeSeer/CAPI regardless if a virtual device was toggled by HomeSeer or mcsMQTT.

- There was no need to enable history settings anywhere in the 3.x mcsMQTT for logging to function correctly (even though the options to do so were present).

I'll update mcsMQTT when it comes down through the official update channel and report back if it changes anything. I'll also set up a test implementation and attempt to recreate the parent virtual device delete issue when I'm finished setting up the new environment. Again, I believe it was triggered by toggling a combination of the "Value Change Event" setting and "Log" setting right under it, but I'll do some testing when I have an opportunity.

[Slab0]

Just an update:

I updated to version 5.24.0.8, and while I'm not precisely sure what may have changed relative to logging, I still need to check the history box on the virtual device to get log entries (still generated by mcsMQTT, not HomeSeer/CAPI).

Is there any way to include the parent device name in the log entry so that it's similar to HomeSeer's native log entries? Assuming I stick with the default 'feature' device name of 'Control' when creating virtual devices, the only way to discern which virtual device a log entry is referencing is to look up the device ID.

[Michael McSharry]

Yes. I can change the log message to include Device name. Probably tomorrow.

I did reorganize the UI for setup of the log on the History tab per your suggestion. It should be In 5.24.0.9. It does not change the functionality so selection of what should be logged in HS log continues to be on a feature by feature basis.

[Slab0]

Outstanding... thank you!