top of page

Using Ring Keypad to Open Garage Door (SmartThings ecosystem) - Part 2

Previous: Part 1

Progress for this post... not much.


  • Added a few logging statements so I can see how things are working.

  • The Ring proximity (motion) sensor events being logged constantly is annoying - turned off the proximity sensor for development purposes.

  • There seems to be a lot of "magic" happening (probably because I'm new to lua and SmartThings) in the base code/libraries that I need to understand more. I can read the code but I'm having a hard time understanding driver lifecycle, events, and so forth. I will look for more/better documentation to get an overview. For example, I can guess where/when update_preferences is called... but how am I to know what the parameters are? Also in that same function, VSCode+Extensions seem to be able to tell me the data structure of args.old_st_store.preferences, but where can I find that structure definition and more about it? I started looking at this because this event was being triggered when PIN is changed, but I don't see how it is actually being set to the device (or is it, due to the security of this preference value so it is only stored on the hub?).

  • Lua is interesting...


Next Day


  • I got tired of picking up and unlocking my iOS device, so installed Android Studio in order to get an Android emulator with SmartThings app installed.

  • Also, found this documentation about device lifecycle, so reading through it now.

  • Now trying to match up the documentation with the hmorsti code to try to understand how things work.

    • device:send (various things: EntryControl:ConfigurationSet, Notification:Get, Indicator:Set

    • device:emit_component_event. <-- tells the device what events we want???

    • device:emit-event. <-- tells the device to do something (in device_added it is "resetting" (avoiding the word "init") the device

    • device.profile.components <-- maps back to profiles.yml file?



Another Day


  • I started a diagram to help understand how driver, device, physical device, zwave, etc interact.



  • Once I started figuring out z-wave command classes, I found the Ring Gen2 Kyepad Z-Wave documentation to see what functionality is supported by the device vs what will have to be supported in device/driver/state (e.g. where can user codes be stored... on device or in the driver like hmorsti is doing?)

    • Indicator v3

    • Manufacturer Specific v2

    • Powerlevel v1

    • Security 2 v1, Security 0 v1

    • Supervision v1

    • Notification v8

    • Configuration v4

    • Battery v2

    • Entry Control v1

    • Does not support:

      • wake-up notification (wake up command class). Not critical, but I do recall seeing a few references to this, so good to note.

      • UserCodes, like the community zwave-lock example

      • DoorLock

  • Now I am looking through this docs for anything else interesting.

    • Configuration CC:

      • Heartbeats, Announcement Audio Volume, Key Tone Volume, Siren Volume, Special Key Long Press Duration, LongPress Number Pad Duration, Proximity Display Timeout, Button Press Display Timeout, Status Change Display Timeout, Security Mode Brightness, Key Backlight Brightness, Ambient Light Sensor, Proximity on/OFF, Ramp Time Config, Low Battery Threshold, Language, Warn Battery Threshold, System Security Mode Blink Duration, Supervisory Report Timeout, System Security Mode Display (always, periodic, off+activity), Languages, Calibrate Speaker. It looks like hmorsti already supports most/all of these.

    • Notification

      • I don't think I'm interested in much here.

    • Huh, those are the only 2 CCs with details listed in that document. Found another technical document, but same story. I may have to rely on generic Z-wave documentation and other examples for the other command classes

    • But this confirms that I will need to store the guest codes on the hub (device table?) and not the physical device.

  • I have ripped out (commented-out) a lot of stuff I don't think I will need - mainly alarm functions that I am trying to abstract away. There is more work to do here, but I'm starting slow and making incremental changes mostly to prove (or disprove) my understanding of how things work.

  • I have added the "lock" capability to the device driver. The idea is that the guest will enter their code and press the "disarm all" button to open the garage door, or "arm away" button to close the garage door. I eventually want the "arm home" button to be the "checkout" function (close the door and send a notification (text) that the guests have checked out -- but that will come later. This is functioning now:

    • disarm all --> "unlock" --> routine to open garage door.

    • arm away --> "lock" --> routine to close garage door.

  • I have also added the vEdge Creator drivers (garage door & light bulb), so that I can easily see on the SmartThings app if/when things are working (and to simulate my real-world case better):


That's a good place to stop for today. Next steps: add lockCodes capability (way to define multiple user codes).


Recent Posts

See All

Comments


bottom of page