Mimolite garage door device driver

Huh?, nothing was removed.

I am out of town and do not have any updates in the last few days.
Does the old driver not work with the zwave.alarmV1 edit
It was excess code that was not used in the DH

The zwave.alarmV1 edit does still work

1 Like

Something was either removed or broken, because in 2.1.0 and prior versions the MIMOLite garage door driver driver was working just fine. In 2.1.2 it stopped working and required removing this line:

zwave.alarmV1.alarmGet().format()

This line didn't have cause any issues in 2.1.0 and prior.

Is there anything missing or not working in the old driver?
To be clear the old DH was an old SmartThings community driver converted to work with HE.

Submit a feature request for the stock HE DH version it is a first version and they are always improving can not ask for more than that.

I am just happy they have made a stock version which means it will continue to be supported.

Mike, My garage door was opening and closing fine in 2.1.0. In 2.1.2 it no longer opened and closed. Imagine my surprise when I tried to open it and it just didn't open? Are you guys really wanting to argue that I imagined the working state of my garage door controller prior to updating my hub to 2.1.2?

The bottom line is that literally every single update I've applied since 2.x was released has caused something else in my homes setup to stop working. My keypads and HSM are still broken. To the point that I put off applying updates because I dread what is going to happen every time I do so.

I'm not saying it didn't work obviously, I am saying that it's unreasonable to have an expectation that we could even attempt to test every conceivable device with every conceivable driver and application, both built in and user for every release.

The choice to update or not is up to you.

Chuck promptly identified the issue, reviewed the user code and even provided some suggestions to optimize the community driver.

Regarding the MIMOlite driver we included, I opened a feature discussion regarding proposed details of the MIMO2+ driver I was intending to develop and release in 2.1.2, there were no objections to the proposed options, these were then carried over to the lite driver.

I believe it's unrealistic to presume that a inbuilt driver designed for a multi purpose device would or will carry the same options as one designed for a very specific use case.

A MIMOlite can be used as a garage door controller, but the device is not explicitly a garage door controller.

2 Likes

Yup. And, FWIW, I am using the new system driver, and my MIMOlite works fine to control my garage door. Took a bit to set things up again, but I'd rather use the system driver.

In this case, a bug was found in our platform and it was fixed. This exposed the error that you see with this driver. The driver was never right, it was always broken, its just that now the brokenness is exposed to you as an error message instead of being swallowed by the platform. So our option is to continue to have the platform broken so that this broken code can continue to work, or to fix the problem in our platform and you will need to fix the problem in the driver that you added. FYI, removing the line is question is not the right solution, that line should be there, but it needs to be fixed. I posted the suggested fix and some debugging options, no one bothered to do the fix, they just commented out the offending lines.

Yes the mimolite can be used for other things which is why I like it but it is likely being used the most as a garage door opener.

Unfortunately I am out the country for another 4 weeks and doing this from my phone.

Can someone do me a favor and test @chuck.schwer code fix to line 208 in the DH
zwave.alarmV1.alarmGet(alarmType: 0x08).format()
and see if it works I thought I tried it (that was a few weeks ago) but maybe I miss read his post and only saw that he said it and other code was unnecessary.

No-one is saying that. But certain changes are obviously going to break functionality. If you blacklist basic Java classes that's going to break things. If you modify the behavior of something so that it goes from silently ignoring an error to completely aborting execution... that's obviously going to break things. You don't need to test anything to know that.

Mike, do me a favor and search the Hubitat community forums for "MIMOLite". There are 23 matching threads. Tell me how many of them don't mention the garage door use case?

Are you really trying to put me into a position where I need to apologize for not having the free time to see and respond to that thread? Given that every thread I could find on the MIMOLite mentions using it as a garage door controller, and likewise every thread asking about garage door controllers mentions using the MIMOLite... It's a bit hard for me to swallow that you needed us to jump into this additional thread to tell you that we need it to work as a garage door controller when so many threads already existed to provide you with that information.

This simply isn't true: It's exposed to me as a non functioning device. That is not the same thing as an "error message". Are you saying there was no way to fix the bug in a way that it could log an error message and not abort the thread that was executing it?

Look: maybe in this case the change in behavior was really needed. But my bigger frustration is that every single update I've applied since 2.x has broken something. Every single one. They can't all be justified right? And it's not always in custom apps or drivers. Sometimes system drivers and apps stop working as well, and those are even harder to track down because I have less visibility into the code they are executing. I've had the built in Keypad drivers stop working, built in Thermostat drivers, built in water valve drivers, etc etc. I haven't opened cases for many of them because I simply cannot keep up with the time investment needed.

I would be much happier if I didn't have to rely on custom code to make basic functionality work. I don't particularly like how much time and effort it takes to do basic things in Hubitat sometimes. We early adopters of the Hubitat platform have been forced into doing a lot of custom code to make basic things like keypads or garage door openers work and then we're "punished" for doing so when every upgrade breaks something in the apps or device drivers that we rely on for basic home security. I get it: You can't test everything. But anytime you're making a change where you know that anything that relied on the old behavior would stop working: That doesn't require testing to know it's going to break stuff. I find it hard to believe that you guys don't have the ability to log error messages without causing the thread to abort execution but maybe there's more too it that I'm not seeing. The fact is that there's a bigger pattern of breakages beyond just this MIMOLite issue and it's getting harder and harder, as user of the product, to justify the time investment needed to keep Hubitat running.

I have 14 Mimolites in place as garage door openers. I would like to request that someone that knows how to write code better than I, please develop a device handler for this purpose. I would and I’m sure others may also donate to the cause.

I cleaned up the code abit removing the excess code and added refresh to the open close due to an issue I was having with (running multiple hubs) the Hubconnect arrival DH sending 2 events each time.

/**
 *  MIMOlite device type for garage door button, including power failure indicator.  Be sure mimolite has jumper removed before
 *  including the device to your hub, and tap Config to ensure power alarm is subscribed.
 *
 *  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.
 *
 *  Updates:
 *  -------
 *  02-18-2016 : Initial commit
 *  03-05-2016 : Changed date format to MM-dd-yyyy h:mm a
 *  03-11-2016 : Due to ST's v2.1.0 app totally hosing up SECONDARY_CONTROL, implemented a workaround to display that info in a separate tile.
 *  08-27-2016 : Modified the device handler for my liking, primarly for looks and feel.
 *  01-08/2017 : Added code for Health Check capabilities/functions.
 *  02-11-2017 : Cleaned up code, and used secondary_control again for messages.
 *  03-11-2017 : Cleaned up code.
 *  03-24-2017 : Changed color schema to match ST's new format.
 *  04-08-2017 : Updated the updated() section to call configuration().
 *  05-19-2017 : Added additional attributeStates to match ST's DTH which should make this work with ActionTiles, and to use contact as the main tile instead of switch due to personal preference.
 *  05-20-2017 : Redefined tiles/names to be similar to the Linear-type opener DTH's, which should make this work with ActionTiles.
 *  05-23-2017 : Made the delay longer for retreiving device info (gets) after the main tile or the refresh tile is tapped.
 *  09-22-2019 : converted DH to Hubitat and added refresh before each action
 *  10-07-2019 : removed extra refresh from open/close it caused to much delay
 */
metadata {
	// Automatically generated. Make future change here.
	definition (name: "MIMOlite Garage Door Controller 10/07/2019", namespace: "Hubitat", author: "scgs350") {
        capability "Momentary"
        capability "Relay Switch"
	    capability "Polling"
        capability "Refresh"
        capability "Switch"
        capability "Sensor"
        capability "Contact Sensor"
        capability "Configuration"
	    capability "Actuator"
	    capability "Door Control"
	    capability "Garage Door Control"
        capability "Health Check"
        
	    attribute "powered", "string"
        attribute "contactState", "string"       
        
		command "on"
		command "off"
        command "open"
        command "close"
	}
}

def updated(){
	// Device-Watch simply pings if no device events received for 32min(checkInterval)
	sendEvent(name: "checkInterval", value: 2 * 15 * 60 + 2 * 60, displayed: false, data: [protocol: "zwave", hubHardwareId: device.hub.hardwareID])
    response(configure())
}

def parse(String description) {
	// log.debug "description is: ${description}"
	def result = null
    def cmd = zwave.parse(description, [0x72: 1, 0x86: 1, 0x71: 1, 0x30: 1, 0x31: 3, 0x35: 1, 0x70: 1, 0x85: 1, 0x25: 1, 0x03: 1, 0x20: 1, 0x84: 1])
    //log.debug "command value is: $cmd.CMD"
    if (cmd.CMD == "7105") {				//Mimo sent a power loss report
    	log.debug "Device lost power"
    	sendEvent(name: "powered", value: "powerOff", descriptionText: "$device.displayName lost power")
    } else {
    	sendEvent(name: "powered", value: "powerOn", descriptionText: "$device.displayName regained power")
    }
	if (cmd) {
		result = createEvent(zwaveEvent(cmd))
	}
	// log.debug "Parse returned ${result?.descriptionText}"
    def statusTextmsg = ""
    def timeString = new Date().format("MM-dd-yy h:mm a", location.timeZone)
    statusTextmsg = "Last updated: "+timeString
    sendEvent("name":"statusText", "value":statusTextmsg)
	return result
}

def sensorValueEvent(Short value) {
	if (value) {
        sendEvent(name: "contact", value: "open")
        sendEvent(name: "door", value: "open")
        sendEvent(name: "switch", value: "on")
        sendEvent(name: "contactState", value: "Door is open, close/off to close")
	} else {
        sendEvent(name: "contact", value: "closed")
        sendEvent(name: "door", value: "closed")
        sendEvent(name: "switch", value: "off")
        sendEvent(name: "contactState", value: "Door is closed, open/on to open")
	}
}

def zwaveEvent(hubitat.zwave.commands.basicv1.BasicReport cmd) {
	[name: "switch", value: cmd.value ? "on" : "off", type: "physical"]
}

def zwaveEvent(hubitat.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd) {
	def doorState = device.currentValue('switch')
    if (doorState == "off")
    	[name: "contactState", value: cmd.value ? "close" : "closing", type: "digital"]
}    
    
def zwaveEvent(hubitat.zwave.commands.basicv1.BasicSet cmd)
{
	sensorValueEvent(cmd.value)
}

def zwaveEvent(hubitat.zwave.commands.sensorbinaryv1.SensorBinaryReport cmd)
{
	sensorValueEvent(cmd.sensorValue)
}

def zwaveEvent(hubitat.zwave.commands.alarmv1.AlarmReport cmd)
{
    log.debug "We lost power" //we caught this up in the parse method. This method not used.
}

def zwaveEvent(hubitat.zwave.Command cmd) {
	// Handles all Z-Wave commands we aren't interested in
	[:]
}

def on() {
    log.debug "Sending on event to open door"
	open()
}

def off() {
    log.debug "Sending off event to close door"  
	close()
}

def open() {
	if (device.currentValue("door") != "closed") {
		log.debug "not opening door is already open"
	}
	else {
        log.debug "Sending open event to open door"
		push()
	}
}

def close() {
	if (device.currentValue("door") != "open") {
        log.debug "Not closing door since it is already closed"
	}
	else {
		log.debug "Sending close event to close door"
		push()
    }
}

def push() {
	log.debug "Executing push for garage door"
	delayBetween([
        zwave.basicV1.basicGet().format(),
        zwave.basicV1.basicSet(value: 0xFF).format(),
	],1000)
}

def poll() {
	refresh()
}

// PING is used by Device-Watch in attempt to reach the Device
def ping() {
	refresh()
}

def refresh() {
	log.debug "Refreshing"
	delayBetween([
		zwave.switchBinaryV1.switchBinaryGet().format(),
		zwave.sensorBinaryV1.sensorBinaryGet().format(),
        zwave.basicV1.basicGet().format(),
//		zwave.alarmV1.alarmGet(alarmType: 0x08).format()
	],1000)
}

def configure() {
	log.debug "Configuring...." //setting up to monitor power alarm and actuator duration
	delayBetween([
		zwave.associationV1.associationSet(groupingIdentifier:3, nodeId:[zwaveHubNodeId]).format(),
        zwave.configurationV1.configurationSet(parameterNumber: 11, configurationValue: [25], size: 1).format(),
        zwave.configurationV1.configurationGet(parameterNumber: 11).format()
	],100)
}

Updated the above code the extra refresh was causing to much of a delay.

To correct for the Hubconnect arrival/presence DH issue I just moved the rule to the zigbee hub
(so I don't use the Hubconnect arrival/presence DH) and sent the garage open command to the Zwave hub.

Tried the stock Hubitat mimolite device handler and just didn't like how it had to be setup.

So I updated the original mimolite DH to be backwards compatible with the stock Hubitat DH and also added door timing and s/w lock.
(thanks to @JasonJoel and @mike.maxwell for helping)

This way is much easier to display and control on your dashboard as well.

the s/w lock ensures that hubitat can not open the door when locked.
Think of it like the manual lock option on the garage door panel on your garage door wall.
not really a mimolite issue but saw when the Hubitat hub started slowing down and was doing a nightly backup that if the hub was running slow it could cause an arrival device to go departed then back arrive again which could accidentally fire rules. Adding more conditions to rules also helps prevent this but adding a s/w lock option will help a lot as well.
Just add lock the garage door to a secure house rule.
To be clear

  • the s/w lock function does not physically disable the lock if you were to put "unlock" and "open door" when you arrived in a rule it would open the door.
    You probably would not use it that way.
    Use the lock function as a separate rule to secure the door unless your car is like mine and only powers the arrival sensor when the car is running (so a slow hub would not affect it).
  • The lock function only s/w locks the garage door when it is closed not open
  • If you manually open the garage door the garage door will automatically go to unlocked.
    - If you use the "push" command in your rules it will bypass both the lock and door timing you need to use the "open/close" or "on" command.
  • added lock and door timing to push command
1 Like

Updated the mimolite DH above
added logic and cleaned up the code
So the DH should never get out of sequence with the garage door and the garage door can not be activated unless open or closed for a set time (default is 20 seconds).
The momentary switch has been set to default 3 seconds on if you want it disabled then set to 0 in the device settings.

Updated the device handler, and now I have no door function? Any ideas? I changed back to old DH and it works.. Thank you.

@jesse.fetterman strange I just copied and pasted from the github back to my hub just to make sure I didn't fat finger anything and it still works fine.
If you enable debug logging and try and open the door do you get any errors?
nothing happens if you try all commands?

Just tried new DH again and got the same results. Tried all commands and only refresh works, not sure why. The log says, no open command sent door is already open. However in the device, the current state is closed and the door is physically closed.