External sensors

[robross0606]

Most of the instructions and design focus on exposing ST devices to external systems. However, I would like to introduce external sensors (motion, open/close, etc.) into ST. It is unclear to me how I could create a device in SmartThings that equates to a device that originated in HomeAssistant. I've seen some discussion of using virtual switches for simple on/off switches, but how can this be done for sensors?

[sgupta999]

okay this is where ST is really finicky. from ST-> bridge is the easy part that is what I coded. Bridget to ST is a black box are you not seeing any live logs for both bridge and smartapp from the server?

[sgupta999]

so 2 things we need to check:

1. make sure the MAC is address is in "aa:bb:cc:dd:ee:ff" form
2. make sure in the smart app config the bridge is selected

[robross0606]

are you not seeing any live logs for both bridge and smartapp from the server?

I am seeing logs for the real ST devices I set up. I see logs for the bridge and the sensors themselves. What I don't see is the data coming from MQTT via the bridge that is supposed to be applied against the virtual sensors.

[sgupta999]

MAc address needs to be mac address of the machine running the mbs-server

[robross0606]

The bridge is WORKING for real ST devices flowing ST->MQTT. What is NOT WORKING is virtual devices flowing MQTT->ST.

[robross0606]

I've already confirmed all those settings. The bridge is functioning. I see logs and data in MQTT confirming communications between the bridge and ST SmartApp. But only for things flowing in one direction. In the other direction, I only see half the logs.

[sgupta999]

ST -> MQTT should work for all devices. MQTT -> ST will also either work for all or none depending on if bridge is configure corrrectly

[robross0606]

lemme go blow away the bridge and try recreating it.

[sgupta999]

half the logs? so you are seeing bridge logs but not smartapp logs

[sgupta999]

in the smartapp config all they way near the bottom make sure bridge is selected and hit save

[robross0606]

Yes, so I see this in the bridge service (node.js) logs:

2019-11-29 11:12:27 AM debug: From MQTT: smartthings/Kitchen Motion/motion/trigger = active
2019-11-29 11:12:27 AM info: MQTT --> ST - Topic: [smartthings/Kitchen Motion/motion/trigger][active]   [Kitchen Motion][motion][active]

But no corresponding log entries on the ST IDE live logs. The other direction, I see logs in both places that correlate.

[robross0606]

aha! We're getting somewhere. I recreated the MQTT bridge in ST and reconnected everything. Now, when I triggered the motion sensor I see this in ST IDE live logs:

50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:25:21 AM: error java.lang.IllegalArgumentException: Command 'active' is not supported by device b59f8d74-3796-44af-b1b6-9d3d459a152a of type 'Motion Sensor Capability'. Supported commands: [] @line 732 (actionActiveInactive)

It's an error but at least it is something.

[sgupta999]

Your bridge should look like this

[robross0606]

It looks similar, yes. I think there was something wonky in there. When I blew it away and recreated it, I'm at least seeing the triggers in ST IDE live logs. Now it just seems like I need to structure my command properly using actionActiveInactive.

[sgupta999]

And in your SmartApp

[sgupta999]

are you using the full or lite version of smartapp . the action command is implemented in the full version - you can copy from there

[robross0606]

I'm seeing this now:

Parsed '{"command":true,"name":"Kitchen Motion","type":"motion","value":"active"}'

But then seeing this:

java.lang.IllegalArgumentException: Command 'active' is not supported by device b59f8d74-3796-44af-b1b6-9d3d459a152a of type 'Motion Sensor Capability'. Supported commands: [] @line 732 (actionActiveInactive)

So that tells me my MQTT command is just structured incorrectly at this point. I am using the full version of the smartapp.

[robross0606]

It is saying Supported commands: [] @line 732 (actionActiveInactive). Is that implying that my chosen device type doesn't support any actions ([])?

[sgupta999]

the command should be there are you using motion handler from Simulated motion Sensor https://github.com/SmartThingsCommunity/SmartThingsPublic/blob/61b864535321a6f61cf5a77216f1e779bde68bd5/devicetypes/smartthings/testing/simulated-motion-sensor.src/simulated-motion-sensor.groovy

[robross0606]

I was using "Motion Capability" but just switched over. I'm looking at the groovy code now. I may actually use a custom one.

[sgupta999]

you could. but just go with the standard one for motions and sensors since they are passive devices anyway - just copy that code and paste in your current device handler and you are done - at least you will be able to check if it is working

[robross0606]

I don't like that the standard ones have tiles for manually changing the state from ST. I have my wife on this thing and she's barely computer literate. 😄

[sgupta999]

from the tiles section just remove the action:active and action : inactive name value pairs she will not be ale to change from the tiles

[robross0606]

Yes, that's what I meant by "custom". I modified it slightly.

[sgupta999]

make these

        state("inactive", label:'no motion', icon:"st.motion.motion.inactive", backgroundColor:"#cccccc", action: "active")
        state("active", label:'motion', icon:"st.motion.motion.active", backgroundColor:"#00A0DC", action: "inactive")

into

        state("inactive", label:'no motion', icon:"st.motion.motion.inactive", backgroundColor:"#cccccc")
        state("active", label:'motion', icon:"st.motion.motion.active", backgroundColor:"#00A0DC")

[robross0606]

okay, so this is confusing. It now appears to set the state to "active" all the way through ST IDE live logs but then almost immediately set it back to "inactive".

50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:57 AM: debug Duplicate of last event from device 'Kitchen Motion', ignoring event 'inactive' on attribute 'motion' for device 'Kitchen Motion'
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:57 AM: debug Received event inactive on attribute motion for device Kitchen Motion for BRIDGE
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:56 AM: debug Calling action method actionActiveInactive, for attribute motion, for device Kitchen Motion with payload inactive
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:56 AM: debug Received device event from bridge: [command:true, name:Kitchen Motion, type:motion, value:inactive]
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:43 AM: debug Duplicate of last event from device 'Kitchen Motion', ignoring event 'active' on attribute 'motion' for device 'Kitchen Motion'
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:43 AM: debug Received event active on attribute motion for device Kitchen Motion for BRIDGE
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:43 AM: debug Calling action method actionActiveInactive, for attribute motion, for device Kitchen Motion with payload active
50e3cfa0-8b6a-4760-99c6-e0301448b22b 11:40:43 AM: debug Received device event from bridge: [command:true, name:Kitchen Motion, type:motion, value:active]

[sgupta999]

thats great - so you should be seeing the two way communication now. frankly my suggestion would be just use the devices.yml , for any device you selecte in the app but is not in the devices.yml it will revert to this legacy behavior

[robross0606]

Almost there but not quite. It appears to set it to active in the logs, but then sets it right back to inactive immediately. It is so fast that you never see it in the dashboard or anything. Any idea why it is changing it back to inactive?

[robross0606]

The "inactive" part seems to come from ST, not via my triggers or anything else I'm doing.

[sgupta999]

let me check something

[robross0606]

I think it may have actually come from Hass after all. I was triggering the state change for these tests via the Hass developer console. I think right after I artificially changed it, ADT Pulse was changing it back. A real sensor trigger doesn't seem to be exhibiting the same issue. I'd call this success. Now to try the same thing for a contact sensor...

[sgupta999]

yes the first line Duplicate of last event from device 'Kitchen Motion', ignoring event 'inactive' on attribute 'motion' for device 'Kitchen Motion'

suggested this is from the server - the server logs should confirm that.

[sgupta999]

glad it was not a switch or it would be a very bothersome loop (i have done it hence all the dupliate checks)

[robross0606]

Goodness, this thing is going to fight me every step of the way. The contact sensor appears to be flowing all the way through. I can see it in the logs all the way to ST IDE:

50e3cfa0-8b6a-4760-99c6-e0301448b22b 12:29:07 PM: debug Subscribed to event contact on device [Garage Inner Door, Front Door]
50e3cfa0-8b6a-4760-99c6-e0301448b22b 12:28:33 PM: debug Received device event from bridge: [command:true, name:Garage Inner Door, type:contact, value:closed]

And yet the dang UI isn't updating at all. 🙄

[robross0606]

What I don't see is any logs under the "Garage Door Sensor" device. Perhaps there's a problem with the handler? I'm using the "Simulated Contact Sensor" without modification.

[sgupta999]

I dont see action event being called. are you seeing any erorr messges or is this the last message you see

[robross0606]

No, that's the last thing I see.

[sgupta999]

in the capability map do you have

"contactSensors": [
    name: "Contact Sensor",
    capability: "capability.contactSensor",
    attributes: [
        "contact"
    ],
    action: "actionOpenClosed"
],

and further down action

def actionOnOff(device, attribute, value) { if (value == "off") { device.off() } else if (value == "on") { device.on() } }

[sgupta999]

sorry def actionOpenClosed(device, attribute, value) { if (value == "open") { device.open() } else if (value == "closed") { device.close() } }

[sgupta999]

action: "actionOpenClosed" needs to be clearly defined in the capability map otherwise app will not know what method to call

[robross0606]

Ahh, that capability did not have an action defined for some reason. It is like that in the repo.

[sgupta999]

that is odd..it should have been there

[sgupta999]

did you use the tamotaSensor or the default contactSensor - i see it in the defaul contactSensor in the repo.

for tamostaSensor I defined my own custom action methods for custom DTH

[robross0606]

https://github.com/sgupta999/mqtt-bridge-smartthings/blob/master/smartapps/gupta/mqtt/mbs-smartapp.src/mbs-smartapp-full.groovy line 159 does not have an action defined.

[sgupta999]

could you please post what you have for capability map there - there are several subtleties with the action attribute there wnat to make sure you get it right

[robross0606]

It is already working once I added the action in there. I didn't modify the smartapp at all. I copied exactly as it is in the repo. The only thing I've added is the action on the contact sensor.

[sgupta999]

good catch - i was looking at the lite version

[robross0606]

The whole process from physical device to registration in ST is pretty slow, but I think most of that is on the Hass (ADT Pulse) side. Better than nothing!

[sgupta999]

not sure I understand - as soon as message from hass hits your MQTT broker it should be pretty quick after that less than 1s. are you saying hass takes a long time for posting to broker after physical device triggers?

[robross0606]

Yes, there's a whole part to this flow that I haven't discussed. The whole point to this is tieing in sensors from an ADT Pulse system (non-Smartthings version). There's an add-on for Hass that is webhooked into ADT Pulse to read sensor states. That part of it is slow. I assume it is polling, but haven't checked the code yet. The process once Hass gets around to publishing is pretty quick.