Diagnosing Possible Loop Condition #34
Comments
|
Okay so the default one using ‘old’ I am assuming in config.yml u did not uncomment state_read_suffix and state_write_suffic and cmd_suffix
If u don’t than read and write will be the same topics and u r getting loops
For the VBS in the SmartApp did u define the capability switches and did u select it from the config screen of the MBS app?
…Sent from my iPhone
On Nov 17, 2020, at 7:48 PM, Josh Bernstein ***@***.***> wrote:
@sgupta999 I really appreciate you continuing to comment here, even though it seems you've moved on. Perhaps at some point once how I understand this I'll be able to take it over/contribute.
Anyway, I'm trying to diagnose a Possible Loop detection. The device in the log "Playroom Wiring Dimmer" was auto added to the bridge when I enabled it in the ST iOS app. So there isn't an entry for it in the devices.yml. I imagine then its falling back to what you call the "old" behavior. I'm just not entirely sure how to address this and could just use some guidance.
mbs | 2020-11-18 01:43:03 AM info: ST --> MQTT: [Playroom Wiring Closet][switch][on] [smartthings/Playroom Wiring Closet/switch][on] mbs | 2020-11-18 01:43:03 AM warn: POSSIBLE LOOP. Device[Attribute] Playroom Wiring Closet[switch] is publishing to Topic smartthings/Playroom Wiring Closet/switch while subscribed to Topic [ 'smartthings/Playroom Wiring Closet/switch' ] mbs | 2020-11-18 01:43:03 AM info: Skipping duplicate message from: smartthings/Playroom Wiring Closet/switch = on
My devices.yml file just contains a single definition. For a Virtual Device Switch in ST (that I can't get to work at all). The Playroom Wiring Closet switch appears in ST from the Brilliant.tech keypads
VDS: subscribe: switch: indigo/VDS/switch: command: 'OFF': 'off' 'ON': 'on' publish: switch: indigo/VDS/switch: retain: 'false'
Any guidance would be appreciated, by on the the loop detection and perhaps why the VDS device isn't registering at all.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
You're spot on. Those three options aren't uncommented, when I did it seems to work. It seems some of the topic paths are cached in data/status.json. So I had to blow to those files away, and then restart. Now I don't have the loop warnings. The issue is that the incoming message to the bridge (using the default set_state field) doesn't appear to be picked up by the bridge and forward over to ST. I imagine then I need something in the devices.yml to map it together properly? I write to the topic for example (smartthings/Playroom Wiring Closet/switch/set_state on) and it doesn't seem the bridge it picking it up. I suppose I need a mapping... Given that you have this flexibility, would say that a proper configuration would have separate topics to receive and send back to ST. |
|
For the VDS switch. Its been added to ST as a Virtual Dimmer Switch. Then in the iOS app, I have it selected in SmartApp. You mention above that I have to define the device capabilities, but I assumed from reading here that the Virtual Device would be built in? I'm just not super clear on what's required there. I have the SmartApp deployed stock from the GitHub repo |
|
Here is my current devices.yml file. With this configuration I can pass an MQTT like this:
If I run a few commands as follows:
The MBS Bridge properly gets the message and passes cleanly to ST. The device then turns on and off. However when I toggle the device in the ST App. Nothing happens. I get no output from MBS. Prior to messing with the state_suffix stuff you mentioned above, it appeared to pass messages properly, from ST->MQTT and from MQTT->ST So Perhaps I'm missing something in my devices.yml? |
|
Going a bit further I've now adopted my devices.yml to this:
This seems now to allows ST to publish the messages BACK to MQTT. So from ST->MQTT
Is there a way to see all possible states ST might send back to the bridge? Also, please let me know how I can thank you for your help on this. You can find me on Twitter @quityourjoshing |
|
Ok so a few things. In the log if you see ST** -> MQTT implies device config is being read from devices.yml
If you see ST -> MQTT it means it using legacy bridge and not devices.yml
Now for each device in devices.yml you are defining your custom capabilities and have the flexibility to override any command behavior.
For each device in devices.yml you have to make sure in MBS-SmartApp there is a capability defined in capability map (multiple devices can have the same capability) and within that capability map u define the commands and action methods that also need to be defined.
The full MBS-SmartAPP several commonly used capability maps and their action methods defined. Follow the README and example.
Once you know what capability map you want to use and the corresponding action method(s) I would suggest delete the ones that you don’t use to create your MBS-SmartApp lite version. Essentially in your capability map and action commands you only want one that you are using.
Now in the iOS app in the smartapp config you have to make sure that you select the appropriate capabilities that you are using and for those pick the device(s) that you defined in he devices.yml
In your example since both of them are switched in devices.yml I would make sure the capability map has something with a switch and the corresponding actionOnOff method defined.
I believe the default lite version of the app already has that.
Now most importantly in the iOS app under that specific capability you have to the two switches.
This should make it work
…Sent from my iPhone
On Nov 18, 2020, at 12:23 AM, Josh Bernstein ***@***.***> wrote:
Going a bit further I've now adopted my devices.yml to this:
Playroom Wiring Closet: subscribe: switch: smartthings/Playroom Wiring Closet/switch/set_state: command: 'OFF': 'off' 'ON': 'on' publish: switch: smartthings/Playroom Wiring Closet/switch/state: command: 'OFF': 'off' 'ON': 'on' retain: 'false'
This seems now to allows ST to publish the messages BACK to MQTT. So from ST->MQTT
mbs | 2020-11-18 06:21:07 AM info: ST** --> MQTT: [Playroom Wiring Closet][switch][off] [smartthings/Playroom Wiring Closet/switch/state][off] mbs | 2020-11-18 06:21:13 AM info: ST** --> MQTT: [Playroom Wiring Closet][switch][on] [smartthings/Playroom Wiring Closet/switch/state][on]
Is there a way to see all possible states ST might send back to the bridge?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
@sgupta999 I really appreciate you continuing to comment here, even though it seems you've moved on. Perhaps at some point once how I understand this I'll be able to take it over/contribute.
Anyway, I'm trying to diagnose a Possible Loop detection. The device in the log "Playroom Wiring Dimmer" was auto added to the bridge when I enabled it in the ST iOS app. So there isn't an entry for it in the devices.yml. I imagine then its falling back to what you call the "old" behavior. I'm just not entirely sure how to address this and could just use some guidance.
mbs | 2020-11-18 01:43:03 AM info: ST --> MQTT: [Playroom Wiring Closet][switch][on] [smartthings/Playroom Wiring Closet/switch][on] mbs | 2020-11-18 01:43:03 AM warn: POSSIBLE LOOP. Device[Attribute] Playroom Wiring Closet[switch] is publishing to Topic smartthings/Playroom Wiring Closet/switch while subscribed to Topic [ 'smartthings/Playroom Wiring Closet/switch' ] mbs | 2020-11-18 01:43:03 AM info: Skipping duplicate message from: smartthings/Playroom Wiring Closet/switch = onMy devices.yml file just contains a single definition. For a Virtual Device Switch in ST (that I can't get to work at all). The Playroom Wiring Closet switch appears in ST from the Brilliant.tech keypads
VDS: subscribe: switch: indigo/VDS/switch: command: 'OFF': 'off' 'ON': 'on' publish: switch: indigo/VDS/switch: retain: 'false'Any guidance would be appreciated, by on the the loop detection and perhaps why the VDS device isn't registering at all.
The text was updated successfully, but these errors were encountered: