Can I Associate an Existing HS Device with an MQTT Topic

[kenm]

I have some HS Devices that were created with another plugin. They are AQI readings that are parsed from JSON data from the PurpleAir sensor site. I want to stop using the other plugin that created the HS devices, but I have a number of scripts and events that use those devrefs.

Using the URL function in mcsMQTT, I've been able to get the JSON data into pseudo MQTT topics. I'd like to associate those topics with the existing HS devices.

Is this possible?

Thanks,
Ken

[Michael McSharry]

You can accomplish what you want from either of two approaches from the Association tab of the MQTT Page

1. In the Ref column (of plugin (green)) row enter the existing Device Ref (do not check the "A" column checkbox to create a new HS Device Feature). When data is received on the pseudo-topic it will be stored in the DeviceValue of the associated Ref. This should result in a mixed (blue) background on the next refresh.

2. Check the "A" column of the non-plugin Ref (pink) row to make the association. Click on the Ref to enter the Edit popup. For the subscribed topic enter the pseudo-topic. When the pseudo-topic is updated it will attempt to use CAPI to control the non-plugin device. Since you do not want to use the existing plugin for this Ref, you should also change the Interface on the Edit popup to be mcsMQTT. mcsMQTT will then take ownership of the Ref.

#2 is what I suggest as this should result in the cleanest result.

If you have any issues let me know. The mixing of non-plugin devices and plugin devices is an area that has not had as much user exercise.

[kenm]

Thanks Michael for the guidance.

I tried option #1 first after I made a copy of the existing HS device. I entered the devref of the copy and got the following:

UpdateDeviceProperties Ref=1520 Source=URL/www.purpleair.com/json?show=12873.GET:results:01:PM2_5Value at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessag e(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(Mess ageData& msgData, Int32 type) at HomeSeer.PluginSdk.IHsController.AddStatusGraphicToFeature(I nt32 featRef, StatusGraphic statusGraphic) at MCSMQTTHS4_2020.MqttAppModule.NumberType(Int32 iRef, Boolean bControlable, MqttReport oMQTT) in C:\Users\Public\Documents\LaptopVM\MCSMQTT2020HS4\MqttAppMod ule.vb:line 7265 at MCSMQTTHS4_2020.MqttAppModule.SetInitialProperties(MqttRepor t oMQTT, Int32 iRef) in C:\Users\Public\Documents\LaptopVM\MCSMQTT2020HS4\MqttAppMod ule.vb:line 7046 at MCSMQTTHS4_2020.hsCommon.UpdateDeviceProperties(MqttReport oMQTT, Boolean bCompleteButtonPair) in C:\Users\Public\Documents\LaptopVM\MCSMQTT2020HS4\hsCommon.v b:line 1251 Line 0 You can only add controls to features


The Associations Tab did show the Device ref and the check mark but it was still all green. Also, when I click on the device ref, the popup window is blank.

This is a Big5 HS device that was migrated from HS3 in case that's relevant.

Thoughts?

[Michael McSharry]

I see "You can only add controls to features". This implies to me that a Device and not a Feature Ref is being managed.

If you have an old HS3 device that does not have the Child/Parent relationship that could explain it. If this is the case, then the first step should be to group the HS3 device under some parent so that it becomes a feature. I suspect the same may be needed for option #2. In both options I have not evaluated trying to change a non-plugin device to a feature, but I suspect there will be problems with doing it.

Grouping can be done on the mcsMQTT Edit page or can be done with JON00 grouping utility.

I can try tomorrow to replicate the scenario of trying to use a Device as if it is a Feature. If my analysis is correct, then I should be able to recognize this within the plugin and accommodate the operation without additional user action.

[kenm]

Dang it. I forgot to make it a feature before using it. I know from the past experiences that I need to do that.

Let me test that out in the morning and get back to you. No need for you to do any testing.

Thanks,
Ken

[kenm]

Option #1 still didn't work. I got the following in the log:

AddMQTTPluginDevices at MCSMQTTHS4_2020.MQTTASP.AddEditEntry(StringBuilder fs, MqttReport oMQTTIn) in C:\Users\Public\Documents\LaptopVM\MCSMQTT2020HS4\MQTTASP.vb :line 6818 Line 6818 Object reference not set to an instance of an object.

The Association Tab still shows all green and clicking on the device ref gets a blank popup.

Let me know what additional info you need to troubleshoot.

Thanks,
Ken

[Michael McSharry]

I did the following for option 1.
1. Created VD 877 with feature 878 for testing
2. On a MQTT receive topic Ref text box entered 878


3. Changed the Association tab filters checkbox to show both non-plugin and pluign devices and T1 filter of Test. This now shows 878 as blue



4. Clicked on 875 Ref button. Observe Owning Interface is blank (as expected for VDs). Sub topic is as expected. I also observed that the Pub topic is not blank. I tried to change it to blank, but it would not allow such a change. This is because a non-plugin device needs to have a pub topic to use when the feature value changes. This implies that each time the sub topic (Test/csv:Zones:01 in this test) is updated a MQTT message will be published on Topic MCS*/...



To avoid this behavior, the Owning Interface was changed from blank to mcsMQTT on the Edit page. Next refresh shows this is a plugin device (green).

Can you describe the steps you used that generated the error? I will be gone for a few hours.

[kenm]

1. Create VD 1521 with a Feature of 1522
2. Using the old deviceutility page, I made a copy of the Bug5 device. The copy is 1530.
3. Using Jon00's Grouping Utility, I made 1530 a feature of 1521.
4. On the MQTT URL topic devref box I entered 1530


5. Changed the Association Filters and 1530 turned blue.


6. Notice that I'm not seeing the Parent Device which is 1521. What's even stranger is when I go to Add/Edit it shows the Grouping Parent Ref for 1521 as 1522, which is the feature I created as a part of the VD.



7. When I try to clear the 1522 Grouping Parent Ref I get the follow: "A Feature must have a Parent Ref." (Didn't capture the message.

8. I tried typgin 1522 back into the same field and I get the following:




Maybe I should just start over fresh with new devices.

[Michael McSharry]

I do not understand what you are doing in your #6 and later. 1530 is the Ref associated with the PurpleAir topic. If you click on the 1530 Ref button on the Association tab does the popup show 1530 at the top or is it showing 1521 as in your screenshot of #6?

#7 response makes sense because editing looks to have been started with the Device 1521. I'm guessing the mcsMQTT looks for an association of 1521 and assumes it must be a Parent Device. I suspect I did not provide edit capability of a Device as I do not think a Device can have a Parent association. I could make mcsMQTT smarter to not even show the Parent text box if the Ref being edited is a Device.

After your step #4 you should have device 1530 DevceValue being updated when PurpleAir topic is received. You will also publish on topic HS4B/... every time the PurpleAir topic is received. I suspect you do not need or want to publish this. To overcome the publish you need to let mcsMQTT take ownership of 1530. This is done from the Edit tab Owning Interface text box.

[kenm]

Ah. I think I confused myself. I'm starting over with a fresh VD and fresh copy of one of the Big5 devices. I'll update in a little while.

Ken

[Michael McSharry]

I started improving the plugin to allow grouping of either children or parents. It should not change what you want to do but could help in the confusion in the future.

[kenm]

I carefully walked through the process again step-by-step and I got all of the way to the Association Tab being green. However, when I click on DevRef button, I get a nearly blank popup.



Using Add/Edit and putting in the DevRef shows the correct info.

As it turns out, it appears that none of the DevRef popups seem to be working for URL topics.

[Michael McSharry]

Good feedback. I will look into it tomorrow.

[Michael McSharry]

I completed the changes to allow either a child features to be grouped under a parent or a parent device to be specified for a child feature. In the case of HS3 devices that do not have parent root devices mcsMQTT will treat them as features and the grouping action will change them to explicitly be features so they will work normally with other HS4 functions.

I did not see any problem with the Ref hyperlink for URL type rows. The update is at mcsMQTT Change Log (HS4 & HS3) - HomeSeer Message Board at the bottom of the first post. If you continue to have a problem look at the HS log and mcsMQTT debug. Additional debug can be added if necessary to isolate the issue with URL that you are having.

[kenm]

Here's what I get in the log when I try to change the Owning Interface from Big5 to mcsMQTT:

AddMQTTPluginDevices at MCSMQTTHS4_2020.MQTTASP.AddEditEntry(StringBuilder fs, MqttReport oMQTTIn) in C:\Users\Public\Documents\LaptopVM\MCSMQTT2020HS4\MQTTASP.vb :line 6818 Line 6818 Object reference not set to an instance of an object.

I've all but given up. At this point it will be faster/easier to change the scripts and events that use the old devrefs to the new ones auto-generated by your plugin.