CAPI error

[Michael McSharry]

To create MQTT device that reports HS3 status:
On association tab include non-plugin devices checkbox. Add other filters if desired to limit Association table size. On the row with the HS device use the "A" checkbox. Row will be refreshed with room to change the publish topic from the default. Background color will be pink.

To create MQTT device that controls an existing HS3 device (and reports HS3 status changes)
Perform same actions as with HS3 status device. On the Association tab row or on the Edit tab enter a sub topic in the text box. This sub topic will be the one that controls the HS3 device. Background color will be purple, but only will change on the Association tab when the table is rebuilt.

To remove a sub on a non-plugin device:
Get to Edit tab or popup by either clicking on the Ref button of the device on the Association tab or selecting the Edit tab and entering at the top the Ref number.
On the sub textbox edit it to make it null. The background will change from purple to pink on the Edit tab/popup. It will not change the color of the row on the Association table until the table is rebuilt.

To remove a sub on a plugin device:
Plugin devices are keyed to the sub topic. If you remove the sub topic (from the top of the Edit tab) the HS device will be deleted. Rather than deleting the sub topic the Association tab "A" checkbox can be used to remove the association and this will delete the HS device too.

[vasrc]

A restart should not be needed. If you have new HS devices that you want to add since last restart then the General tab has a button to enumerate the HS devices.

I'm not clear if your restart caused you to have or not have a CAPI issue. If there is a difference after restart then there is something I am not saving to the database when the change you are making occurs.

It was the change to the Sub Topic that I believe caused it to fail. When I first created the Pub topic (on the Edit/Add tab), I had some issues getting it to create without a Sub Topic (at least it wasn't clear to me that it had or had not been created, but that could have been me). Nonetheless, I did add a Sub topic (unnecessary now it seems) that didn't (seem to ) get accepted until the plugin restarted. At least that's what I believe occurred. I can duplicate the failure by entering in a Sub topic that's the same as the Pub topic and then restarting the PI. Reversing that operation fixes the problem (ie removing the Sub topic completely). Again, on the Associations tab.

Not sure how to edit a Sub/Pub topic rcd after it's created on the General tab??

Thanks,
Z

[Michael McSharry]

A restart should not be needed. If you have new HS devices that you want to add since last restart then the General tab has a button to enumerate the HS devices.

I'm not clear if your restart caused you to have or not have a CAPI issue. If there is a difference after restart then there is something I am not saving to the database when the change you are making occurs.

[vasrc]

Correct inference
That worked. Keep forgetting to restart the PI to make the changes take effect.
I'm guessing it worked until I rebooted at which time the incorrect Sub Topic took effect.

Thanks,
Z

[Michael McSharry]

I infer that what you are trying to do is publish via MQTT the status changes of the device. If this is the case then the subscribe topic is not applicable. You should be able to define the association without a subscribe topic. That is what should happen after you check "A" for a non-plugin device. The background will be pink. If is is a 2-way device with both status and control then define a sub topic. The background will then be purple.

[vasrc]

OK, working now, but not exactly sure why.
I threw together a quick script to turn off Status Only but that caused the PI to send 0, so turned it back on. It's back to Status only and Status in the Graphics.
Found the Publish record had both the Sub and Pub topic the same so I changed the Sub to something else (Since I'm not using it) and it's fine again. Should I not have a Sub Topic in the Pub record?

Z

[Michael McSharry]

What is your use case? If you want to publish the status of the device then CAPI is not used. Only when you have an external MQTT topic trying to control the device is CAPI used?

[vasrc]

Looking at the code it seems that no CAPI control is returned for device 2114. Your log shows the first line that has ref & value. It does not show the debug output for each of the CAPI control items which seems to indicate that hs.CAPIGetControl(iRef) returned no entries for it.

Not certain as to what to suggest. The debug is pretty high resolution in this area. I am looking at the source for 3.6.2.0 but I do not think this area has changed since at least 3.4. There are no error traps in the code segment, but don't think an exception is being generated since nothing is showing up at a higher level that will catch the exception and show something in the log.

It's not a CAPI device, it's status only. The plugin it's attached to just places the value inside it (Well water depth). Since it's not controlling anything, the status setting overrides any CAPI action if I remember correctly??
So you're assuming that all sources of data to be published will be controlled? Probably because they're typically a two-way device (ie send data, receive control) ?

I can modify it to be a non-status device, as soon as I remember how (Ed?). (BTW, nifty tool)

Z

[tenholde]

You can use tenScriptAid to look at the device and see what CAPI controls are defined for it.

[Michael McSharry]

Looking at the code it seems that no CAPI control is returned for device 2114. Your log shows the first line that has ref & value. It does not show the debug output for each of the CAPI control items which seems to indicate that hs.CAPIGetControl(iRef) returned no entries for it.

Not certain as to what to suggest. The debug is pretty high resolution in this area. I am looking at the source for 3.6.2.0 but I do not think this area has changed since at least 3.4. There are no error traps in the code segment, but don't think an exception is being generated since nothing is showing up at a higher level that will catch the exception and show something in the log.

       Dim arrCAPI As CAPIControl() = hs.CAPIGetControl(iRef)
        If gDebugLog Then
            hsWritelog(PLUGIN_DEBUG, "Command nonPlugin Device " & iRef.ToString & " to " & sValue)
        End If
        For Each oCAPI As CAPIControl In arrCAPI
            If oCAPI IsNot Nothing Then
                If gDebugLog Then
                    Dim sRange As String = "Nothing"
                    If oCAPI.Range IsNot Nothing Then
                        sRange = oCAPI.Range.RangeStart.ToString & " to " & oCAPI.Range.RangeEnd.ToString
                    End If
                    hsWritelog(PLUGIN_DEBUG, "Command " & iRef.ToString & " to " & sValue & ", nValue=" & nValue.ToString & ", ControlValue=" & oCAPI.ControlValue.ToString & ", Range=" & sRange & _
                        ", ControlType=" & oCAPI.ControlType.ToString & ", ControlString=" & oCAPI.ControlString & ", Label=" & oCAPI.Label & ", ControlUse=" & oCAPI.ControlUse.ToString)
                End If

[vasrc]

Any idea where I should look for this? Just started occuring either after update or reboot.

Apr-10 3:14:55 PM

mcsMQTT

Unable to find CAPI control 94.93 for device 2114

Apr-10 3:13:55 PM

mcsMQTT

Unable to find CAPI control 94.93 for device 2114

Apr-10 3:12:55 PM

mcsMQTT

Unable to find CAPI control 94.91 for device 2114

Debug shows OK:
4/10/2019 3:04:00 PM 5464 | Update Accepted 2114 to 95.05 StatusType=0
4/10/2019 3:04:00 PM 5469 | Command nonPlugin Device 2114 to 95.05
4/10/2019 3:04:00 PM 5471 | ActoOnMessageForTrigger Topic SHELTERMONITOR2/system/water/level,Payload=95.05

It's a simple Publish from another Plugin device value. Status only. Worked previously.

Thanks,
Z