Simple/efficient way to delete unused VPS's and/or disable auto creation

[Guest]

It was not problematic and I can put it back. I was just trying to achieve consistent operation to make the user feel more comfortable. Buttons also use the VSP list so it seems like if one is done then both should be done. Let me know what you think is best.

I generally don't have a large number of VSP to input so manual could be fine;
but with the new "limit" implemented and since it's already developed, I think it's worth keeping the "automatically sync HS VSPs" feature with some "enable/disable" checkbox besides the "Clear existing VSP" button.

Especially in the current situation where I am stuck with 300 invalid VSPs in the HS device, I was hoping to "clear" the VSP list on the MCSMQTT side so it would automatically delete HS VSP's. Is this the intended behavior (Mirror Sync) ?

otherwise I'm in for a long sequence of "delete" pressing in HS.... (for some reason, when the number of VSP is high, it takes forever to update between deletions)
Or if someone has a better way to batch delete VSPs in HS, I am open to suggestions =)

Thx,

[Michael McSharry]

I did fix the VGP edit in http://mcsSprinklers.com/mcsMQTT_5_11_5_1.zip. It is uploading now.

Each time you make an entry in the VGP edit the VGP relationships are synchronized with HS Device. If you now have 300 entries and only want 3 then edit the database to get the three that you want. Start the plugin. Go to Edit tab and copy one of the three and paste it in the edit box. It will not change the VSP, but it will cause the VSP to synchronized with HS so whatever was in HS is cleared and the new values mirrored from what was on the Edit tab.

I think I will leave the implementation as it is now without the automatic update. If new payloads are received it is more likely it will contain of mixture of desirable and undesirable entries so a manual edit will be done anyway to remove the undesired ones.

[Guest]

Works like a charm, thank you;
The only thing I may recommend is to "overwrite" data when the edited value already exists. See example below.
otherwise only a single VSP shows on the edit tab and unless you use the database you won't notice the duplicates.

[Michael McSharry]

The only thing I may recommend is to "overwrite" data when the edited value already exists. See example below.
otherwise only a single VSP shows on the edit tab and unless you use the database you won't notice the duplicates.

The design is intentional so it can support many-to-one relationships. Take a scenario where a device reports states ModeA1, ModeA2, ModeA3, ModeB. From the HS perspective the user may want to have only ModeA and ModeB so needs to map ModeA1, ModeA2 and ModeA3 into a single numeric VSP value.

What I can do is provide a popup warning that a duplicate was entered.

[Guest]

Makes sense; not a big deal here as I'm using the DB;
If feasible you could show the full DB including duplicates ? otherwise the warning is good.
Thanks again.

[Michael McSharry]

Yes, I notice this when I was testing the warning. http://mcsSprinklers.com/mcsMQTT_5_11_6_1.zip (HS3/HS4) and http://mcsSprinklers.com/HSPI_mcsMQTT_5_11_6_1.zip (HS4). 30+ min on upload.

[Guest]

Works like a charm, thank you.