It looks like the github commit that broke the Hubitat remote also broke the ST remote. Just pushed the fix to the ST client too a little while ago.
You should be good to go.
2 Likes
I can’t wait to have this running on my PC beside Homebridge.
1 Like
I've got a couple of (seasonal) power switches that I'm not going be using for a while; they're unplugged and in the cupboard. I've disabled them via the red cross on the device page (on the remote hub). What is best practise for the server hub? Disable or leave them?
1 Like
I think that would be your preference. Their instances on the Server Hub aren't doing anything, nor are they part of a mesh. You could leave them there without harm. However, you should do a Z-Wave repair on the hub you removed them from, so your mesh can re-route.
Is anyone else not seeing Ring Doorbell "dings" (button pushes) come through from ST to Hubitat? I confess that I did modify the ST Remote Client to select for device.RingDoorbell instead of device.RingDoorbellPro (I don't have the Pro), but I imagine they both send a button event for "1 pushed" in the same way, so I'm assuming that isn't the problem. I do see the push logged on ST, so I know the problem doesn't start that far back. Additionally, motion comes through fine, so I have no reason to believe anything is wrong with the HubConnect device. Could it be something with the "button translation" between platforms? I'm happy to test anything or try any ideas anyone has. Thanks!
To be honest, I couldn't get it to ever work right either. The button implementation is completely different between Smartthings and Hubitat which is why I think that's the case. I actually got it working partially before but I gave up on using ST to HubConnect for my Ring devices and using the Unofficial Ring Integration located here instead created by @codahq :
I have it setup on my Server hub and using my own custom drivers so the devices are on my other hub that I use for the outdoor motion events so it triggers to turn lights on with motion and button events on my ring devices.
Below is the custom driver I created for myself for my Ring Doorbell:
/*
* Copyright 2019 Steve White
*
* Licensed under the Apache License, Version 2.0 (the "License"); you may not
* use this file except in compliance with the License. You may obtain a copy
* of the License at:
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
* WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
* License for the specific language governing permissions and limitations
* under the License.
*
*
*/
metadata
{
definition(name: "HubConnect Ring Doorbell Pro", namespace: "shackrat", author: "Steve White")
{
capability "Motion Sensor"
capability "PushableButton"
capability "Sensor"
capability "Actuator"
attribute "statusMessage", "string"
attribute "active", "string"
attribute "version", "string"
command "sync"
}
}
/*
installed
Doesn't do much other than call initialize().
*/
def installed()
{
initialize()
}
/*
updated
Doesn't do much other than call initialize().
*/
def updated()
{
initialize()
sendEvent(name: "numberOfButtons", value: "1")
}
/*
initialize
Doesn't do much other than call refresh().
*/
def initialize()
{
refresh()
}
/*
parse
In a virtual world this should never be called.
*/
def parse(String description)
{
log.trace "Msg: Description is $description"
}
/*
pushed
Pushes button #<btn>.
*/
def pushed(btn)
{
// The server will update pushed status
parent.sendDeviceEvent(device.deviceNetworkId, "pushed", [btn], stateChange: true)
}
/*
refresh
Refreshes the device by requesting an update from the client hub.
*/
def refresh()
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "refresh")
}
/*
sync
Synchronizes the device details with the parent.
*/
def sync()
{
// The server will respond with updated status and details
parent.syncDevice(device.deviceNetworkId, "ringdoorbellpro")
sendEvent(name: "numberOfButtons", value: "1")
sendEvent([name: "version", value: "v${driverVersion.major}.${driverVersion.minor}.${driverVersion.build}"])
}
def getDriverVersion() {[platform: "Universal", major: 1, minor: 1, build: 1]}
Once stub driver is installed, create a custom driver like this:
You can remove Pro off of the name if you want, doesn't really matter since it's the same for Pro vs non Pro.
Here's an example when I pushed my doorbell button just now using this custom driver on my other hub using HubConnect:
I have been unable to get a custom temperature device driver to work.
produces this error:
with this log:
what am I doing wrong?
also, how long should the driver report take to load? it seems like it just cycles through and never loads. it says gathering the report from server hub, then it states it is gathering report data from each one of my hubs, briefly flashes the report for about 1/2 second, then starts over again with the server hub and the process repeats. the logs are empty regarding this.
Unable to duplicate.
I got this in my logs:
app:1 2020-01-05 09:31:49.183 am debug Saving custom driver map: [customtemp:[driver:HubConnect Temperature Sensor, selector:E0A9FC6EB029BC74_temperatureMeasurement, attr:[temperature]], tempGV:[driver:HubConnect Omnipurpose Sensor, selector:2C4FDBBB9B4A772A_temperatureMeasurement, attr:[temperature]], sprinkler:[driver:HubConnect EtherRain, selector:9F1DBA6FA926EAA5_switch, attr:[switch]]]
Showing 3 Custom Drivers. I don't happen to use any of these Custom Drivers, they are just debris leftover from previous tests. I'm also on the "next" version of HubConnect (v1.7) but I don't remember anything in this area being changed. v1.7 is all focused on the extra feature of an external Server/Proxy.
For the record @csteele and @srwhite , I get a ton of errors when trying to use hubconnect repeated keypads in HSM as well, as @bfara83 reported earlier.
The keypads work fine in HSM on the hub they are physically connected to.
I see this on the devices:
dev:12892020-01-05 02:26:26.773 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_shackrat_HubConnect_Keypad_1057.disarm() is applicable for argument types: (java.lang.Integer) values: [0] Possible solutions: disarm(), siren(), is(java.lang.Object), isCase(java.lang.Object) (disarm)
dev:12892020-01-05 02:25:58.462 pm errorgroovy.lang.MissingMethodException: No signature of method: user_driver_shackrat_HubConnect_Keypad_1057.armAway() is applicable for argument types: (java.lang.Integer) values: [90] Possible solutions: armAway(), armHome() (armAway)
and this in HSM:
app:3172020-01-05 02:27:25.795 pm errorjava.lang.IllegalArgumentException: The JSON input text should neither be null nor empty. on line 1409 (armNoticeHandler)
app:3172020-01-05 02:27:05.371 pm errorjava.lang.IllegalArgumentException: The JSON input text should neither be null nor empty. on line 1409 (armNoticeHandler)
Does the HubConnect driver account for arming delays coming from HSM along with the armAway command? It looks like it's only set up to receive armAway() instead of armAway(90). For a virtual keypad, they delay can just be passed to the real keyboard with the same method. Once the real one is armed, that should arm the virtual one.
I think I fixed the errors with a driver @csteele sent me to try along with updates I did to that driver for my keypads. Problem last week was they were acting crazy and started randomly arming HSM when HSM had those keypads setup. I didn't have time yet to try to figure out why but the keypad drivers definitely are broken as is right now with some of the functions. @srwhite @csteele, any chance to check on the keypad driver to see if it can be fully functional for 1.7 release 
This is the correct and the expected behavior. According to the official documentation, the securityKeypad capability does not support arguments for armAway().
SecurityKeypad
Device Selector
capability.securityKeypad
Driver Definition
capability "SecurityKeypad"
Attributes
codeChanged - ENUM ["added", "changed", "deleted", "failed"]
codeLength - NUMBER
lockCodes - JSON_OBJECT
maxCodes - NUMBER
securityKeypad - ENUM ["disarmed", "armed home", "armed away", "unknown"]
Commands
armAway()
armHome()
deleteCode(codeposition)
codeposition required (NUMBER) - Code position number to delete
disarm()
getCodes()
setCode(codeposition, pincode, name)
codeposition required (NUMBER) - Code position number
pincode required (STRING) - Numeric PIN code
name optional (STRING) - Name for this lock code
setCodeLength(pincodelength)
pincodelength required (NUMBER) - Maximum pin code lentgh for this keypad
setEntryDelay(entrancedelay)
entrancedelay required (NUMBER) - Entrance delay in seconds
setExitDelay(exitdelay)
exitdelay required (NUMBER) - Exit delay in seconds
It would appear that the physical drivers that you are virtualizing have extended functionality beyond the official spec. I would recommend creating a custom driver if you need to pass a specific parameter to HSM.
Okay...but the logs are telling you something different aren't they?
Remember, hubitat documentation cannot always be guaranteed to be up-to-date with what is actually implemented.
Nope.. There is no match for an armAway() method with an integer as a parameter. And there isn’t. The driver is behaving correctly according to spec.
Well, I can only build to what’s defined. Therefore, until someone from Hubitat clarifies otherwise, this is not a bug and a custom driver is the best solution for this use case.
So, what are you saying? The logs are lying?
Well, that isn't true. You can build to whatever is reported, if you wanted to. But that said, I understand what you mean.
The driver in question is the Iris V3 Keypad in-box driver.
Maybe @mike.maxwell can update https://docs.hubitat.com/index.php?title=Driver_Capability_List#SecurityKeypad to include this functionality - as you are correct that the in-box Iris V3 Keypad driver does not function the way that page lists the commands.
1 Like
Nope. But I don’t think you understand what they’re reporting.
My keypads are using official drivers for my Iris V2 and Xfinity XHK1-TC keypads
What I found was causing the error was the delay option is missing which is fixed as shown below:
/*
armAway
Arms the keypad to "Away".
*/
def armAway(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armAway", [delay])
}
/*
armHome
Arms the keypad to "Home".
*/
def armHome(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armHome", [delay])
}
/*
armNight
Arms the keypad to "Night".
*/
def armNight(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "armNight", [delay])
}
/*
disarm
Arms the keypad to "disarmed".
*/
def disarm(delay)
{
// The server will update status
parent.sendDeviceEvent(device.deviceNetworkId, "disarm", [delay])
}
This cleared the errors for me and no longer get errors but I haven't checked yet what was causing the odd HSM behavior I had last week, I was going to put HSM on the hub with the actual keypads on it to test to see if I can replicate it as it may not be related to HubConnect.
There's no need for insults. Its not rocket science. You can clearly see that the method is being called with a value of 90. I'm not an idiot.
