Hello! I’m hoping someone can help me out with some ThingShield woes. My goal is to use a ThingShield an context-sensitive alarm speaker - but the training wheels/proof-of-concept/for-the-sake-of-conversation version would be to simply turn on the ThingShield LED when a motion sensor trips. Think ThingShield as one-bit output, at minimum. I can get the ThingShield to work beautifully as a device, but I’m struggling to get a SmartApp to listen to the motion sensor and drive the Shield.
I’ve got a motion sensor and standard lightswitch installed. They work great. The ideal thing would be to add a dirt-simple smartApp that points one motion sensor to one switch - but that can come later. Presently, my thinking for involving the fewest me-induced mistakes is to use the provided switch-like device type (the baked-in and available from the device type graphi.api dropdown version of the same seems broken) and some proven-working motion-sensor-driven-switch SmartApp (Specifically bob’s The Flasher - because the wizard-built lights-on-motion thing also seems broken). The Flasher will drive my lightswitch perfectly, and send logged ‘on’ or ‘off’ commands to the Thingshield which are charmingly ignored. The biggest clue I’ve found is that functional device-panel-produced ‘off’ events have commandId 289, where the good-for-the-lightswitch but bad-for-the-thingshield ‘off’ events have commandId 387. Is this some zigbee-vs-zwave thing that’s beyond my simple mechanical engineer, matlab-grown coding chops? Or some switch-specific ‘off’ versus a generic ‘off’ that are respectively parsed correctly and incorrectly by the ThingShield device handler?
Another angle I tried was taking a bog-standard Alarm device type and sprinkling the occasional
zigbee.smartShield(text: “strobe”).format()
or similar into each standard subroutine. This while still running the provided 'duino code which ought to barf back any successfully transmitted messages, even if the Arduino doesn’t have code to handle them - but to no avail. I suspect my troubles lie in the device handler parse method (method, right?) possibly stripping out generic commands - specifically the following line in the ‘def result’ neighborhood:
value in ["on","off"] ? "switch" : (value && value != "ping" ? "greeting" : null),
Yet the ‘hello’ command sneaks though. Can someone give me a pointer on how to learn more about this? Or the right vocabulary term to pick up a Google Degree in the appropriate skills. I’m hip to more basic manipulation strings and boolean-ing in a Matlab sense, but this Groovy style is new to me.
I’ve trawled the forums and wider internet for all things ThingShield and tinkered with (read: mutilated) some existing code, but to no success. Most stuff I’ve found seems to use the Thingshield as an input to the cloud - which is awesome, but not what I’m looking for. For anyone barking up the same tree, I’d recommend hitting:
The official dev documentation
The official Thingshield documentation
jordanrejaud’s unofficial compilation of docs
stevesell’s Garage Door Controller
ogiewon’s extension thereof and virtual sensor work
and craig lyons’ ADT integration
rickbullotta’s got some insightful questions in an old (dead?) thread that might accrue answers with time
Long story short:
-What’s the deal with the given ThingShield device handler working as a device but not with an app?
-What’s wrong with adding zigbee.smartshield commands to an existing, super-basic handler?
Many thanks to any who’ve read this wall-o-text, and even more to the gracious few who might reply.
Best,
-Ben