HS4 vs mcsMQTT device management

[vasrc]

Is there a method that allows HS4 device configuration as well as being included in mcsMQTT. Whenever a change is made in an mcsMQTT edit, it overwrites the device config I made in HS4, particularly images are defaulted, as well as Col and Row values. Looking at the code, it looks like this is by design.

I thought perhaps it was due to being an mcsMQTT device, so I removed the Interface name, but it then reverts to a red page with only Pub info on it, no Sub?

Tnx

[Michael McSharry]

I ran into the same issue for a device that has 16 VSP and I wanted the graphics custom. I later Edit tab this device and lost what I has setup. I tried to make the pluign logic smarter to not change those, but the algorithm had other side effects that caused other user problems so I abandoned the smart logic. I think the logic I used was to have MISC property NoGraphicsDisplay default to true and then if it was false when a device is being updated the image was not updated. Another approach may be to see if a VGP exists and if it does then don't change it.

I will revisit this. For now finish your Edit and Association tab changes in mcsMQTT then make your edits in HS.

[vasrc]

Will do.
I can get the Controls section to behave mostly using "Button". The Column changes are manageable. The Status/Graphic section is the biggest issue.
Perhaps have an option to turn off the PI device config, once created? Seems syncing all device config between the PI and HS4 might be problematic...

Thanks,

[Michael McSharry]

I had all the logic in place for Button and List types, but had captured the existing graphics after I cleared them for the Button. This is fixed in 5.16.0.6 http://mcsSprinklers.com/MCSMQTTHS4_51606.zip for HS4 and http://mcsSprinklers.com/MCSMQTT_51606.zip for HS3.

Was there anything else that needs to be retained as Edit tab changes are made?

[vasrc]

I'll test it a bit later today. I just got a config working that lets me do some testing.

Overall, it seems a bit "aggressive' in what it changes for a small edit (Edit Pub Topic does much more that that) Some of the other issues could also be HS4 with it's value/Status interactions, as well as the way I'm using some of the mcsMQTT devices (ie Value AND String).. Value/String creates two mcsMQTT records for the same HS4 device, but allows you to configure each one separately.. HS4 was confused by that as was I

I also couldn't get my Publish to work without making additional (and different) VGP entries in mcsMQTT. They seem to take precedence over the HS4 values. I get having an internal dictionary to speed things up, but ensuring it's synced up with HS4 devices seems difficult to do..

Thanks, LYK

[Michael McSharry]

$$LABEL:, $$VSP:, $$STATUS: replacement variables all refer to very similar information depending upon if a control label or control status information is desired. $$LABEL: is passed by HS while the other two are the mcsMQTT VSP items. $$LABEL: has a HS bug for the selector control. I forget which one, but there is a VSP property that is write-only so when the plugin reads the HS VSP it is not able to clone it into it's VSP view of the world. This means that the only sync that is possible is to sync HS to mcsMQTT. For things like name, and locations mcsMQTT does sync to HS.

[vasrc]

Still being overly aggressive..

Changed Max # of VSP from 12 to 2 and it wiped out all of the HS4 device control and Status/Graphic settings..
Also looks like it tries to save every String value it gets (which is a LOT when the string is the current total water volume used).

Also, on startup it thought there was a missing HS4 device and created a new one. The device it thought was missing, was an previous HS4 device that had been deleted earlier, so probably a leftover in the DB I suppose?

I've dug into the code to see what's up, which isn't a simple task anymore, as you've been busy, it's a LOT bigger now
I'll do some more testing tomorrow..

Thanks,
Z

[Michael McSharry]

If you want to work with the source then the delta from what you have is at http://mcsSprinklers.com/mcsMQTT_Source_51606.zip

[Michael McSharry]

How do you reproduce your two observations of VGPMax reduction and repeated string storage? Is the storage in the database or the HS device?

What I did do for next update was check for a reduction in VGPMax and remove the excess entries and sync HS device with the shorter list.

[vasrc]

Last time was a simple change in MaxVGP from 12 to 2. That removed all of the Control and Status/Graphic settings. Other times it was an edit of the Publish topic (xxx/xxx/zone1 to xxx/xxx/zone2). The "overwrite" seems somewhat random, as it doesn't seem to always be the same type of change. Sometimes it removes the Control, sometimes it replaces it with a large +/- range, so I'm not 100% positive what's triggering it.

The changes are "always" in HS4 as far as I can tell. I don't use the mcsMQTT device options except at initial config. Most of the other changes are to modify mcsMQTT functionality (ie Pub/Sub/Max, etc)

I just tested the MaxVGP again, and I can't get it to fail now, so it may be a Value/String config issue/difference because there are two records tied to the same HS4 device and not with normal Value records. I've finally got a stable HS4 device config for Value/String devices so I can check both Value/String as well as just Value devices, so I plan to walk through both of them tomorrow and see if I can catch what/when it actually changes. Another possibility is that the refresh on MQTT.html seems to "stall" at times, and doesn't respond to any mouse clicks, so I'm forced to "reload" (by re-accessing MQTT.html not with the Reload icon), which might actually be involved in some of the changes as well.

<IFCHANGE is working great however

Will LYK

[vasrc]

OK, not an exhaustive check yet (just Pub topic change) but I've found a couple of items:
Setup (PI vers 5.16.0.5)
Created a new Value (NOT Value/String) mcs Rcd with associated HS4 device.
Button type, Not Status (Config attached - mcsRcd.png)

In particular:
Change Pub Topic -> SUBTOPIC -> UpdateCommandType -> UpdateDeviceProperties:
The culprits seem to be:
hs.ClearStatusControlsByRef
hs.ClearStatusGraphicsByRef

Not sure why:
A. Pub change would need change HS4 device properties (updateDeviceProperties is used quite often for other PostBack calls)
B. Why the changes made didn't accomodate/recognize the original HS4 device config before overwriting them?

Also:
When running in Value/String mode (ie two mcs Rcds w/one HS4 device). The MISC fields aren't sync. Which ever mcs Rcd is changed last is what the device becomes. So if you set the String to Status Only, HS4 device will change, but the mcs Value record will still show Status only Unchecked. More confusing that anything, but in V/S mode, both need to be the same settings.

Along the way I've also found:
On PI update (new vers) ALL of device selection checkboxes are checked (Show All, Include non-plugins, Include Recvd). Once any are reselected, they operate correctly (ie only All or other is allowed).
On PI restart, it comes up with invalid checkbox configs as well (ALL + Include Rcv)

Thanks

mcsMQTT originial rcd - The resulting rcd after change is the same UNLESS a matching Topic is rcvd and then a new VSP rcd is added. I'm not 100% positive, but those values might be used to create the "modified" HS4 device config



Before (left) and After (right) configs of the HS4 device

[Michael McSharry]

Pub change would need change HS4 device properties (updateDeviceProperties is used quite often for other PostBack calls)

The typical scenario is from no pub to some pub topic. This needs to create the HS button/list etc.so properties are updated to reflect the rendering that is used. A check could be made to not do this when a prior pub topic exists

Why the changes made didn't accommodate/recognize the original HS4 device config before overwriting them?

It does this for graphics and location information. VSP's are driven by MQTT received data so mcsMQTT is considered the master. MISC properties are dependent upon a publish topic so some need to be set without consideration for prior settings. Once this is done then it is less confusing to consider mcsMQTT the master of the MISC for the plugin.

When running in Value/String mode (ie two mcs Rcds w/one HS4 device). The MISC fields aren't sync. Which ever mcs Rcd is changed last is what the device becomes. So if you set the String to Status Only, HS4 device will change, but the mcs Value record will still show Status only Unchecked. More confusing that anything, but in V/S mode, both need to be the same settings.

Since the HS device properties need to align with a mcsMQTT Control/Status UI it is expected that the second one will be the final settings. It is not clear to me what & why some settings need to be the same. Can you provide example?

On PI update (new vers) ALL of device selection checkboxes are checked (Show All, Include non-plugins, Include Recvd). Once any are reselected, they operate correctly (ie only All or other is allowed).
On PI restart, it comes up with invalid checkbox configs as well (ALL + Include Rcv)

I'll look at this, but dont see why plugin update makes any difference. Information is in mcsMQTT.ini so any restart of the plugin should yield the same initialization of the settings.

mcsMQTT originial rcd - The resulting rcd after change is the same UNLESS a matching Topic is rcvd and then a new VSP rcd is added. I'm not 100% positive, but those values might be used to create the "modified" HS4 device config

I am not understanding what you are trying to indicate here and with the screen shots below the statement.
I do see a VSP with no entries for button. It makes sense if clear VSP button is used. How did you create this situation?
I also see a On/Off with swapped values. The plugin tries to make Off=0, On=1.

[vasrc]

Let me restate this:

My issues seem to be primarily cosmetic (ie Labels, graphics changing). Functionality is still there most of the time.
If I don't go into the mcsMQTT device editor, I can keep my HS4 settings.

Being Master, mcsMQTT does seem to be a bit too "broad brush" in what it changes for simple edits. Not supporting (that I can find) the graphic images selected in HS4 does take some of the functionality away, but as I said, once it's configured, I just need to not touch it..

The VSP changes using inputs does look like it may be a concern to me in running the Value/String mode, since the String values returned will have no relationship to how the device should be configured (ie rcv only, for display). I'll just stay out of the editor.

Let me play with it more, I'm still trying to understand how the internals work. If I do have more issues I'll report them singularly and with an example.

Tnx