Shelly 1 for garage door control


#1

Hey guys,

I've got a Shelly 1 I'm developing a custom device driver for and have everything working (seemingly). That being, as a switch and a contact.

I want to use this thing to monitor the opened/closed state of a garage door (the contact), and actuate the garage door open/close (the switch).

The driver uses MQTT and I've developed it based off of a generic MQTT driver and it talks to a server I've got running on a Synology NAS.

Anyway, everything seems to work fine and I can control the open/close switch via a dashboard tile (switch). And I can monitor the opened/closed state of the door contact via another dashboard tile (contact).

What I really want instead, is a single dashboard tile that can both control the door switch and display the contact state.

I've done a bunch of digging and playing around with a couple solutions I thought might work, one being "pmckinnon" Virtual Garage Door Manager, which is an app that you use and add a virtual garage door driver/device, and point the manager to your switch and your contact, which in my case is the same device, the Shelly 1. The dashboard tile I set up using the Garage Control template and so on. The virtual garage door device doesn't talk to the Shelly 1 I've pointed to via the app for some reason, so I'm not sure what the deal is. So obviously the dashboard tile won't work either.

Anyone have any ideas, as I've been spinning my wheels on this for a couple weeks??

Thanks!


#2

Your driver needs the Garage Door Capability. That has all the commands that you need to use the Garage Door (control) tile. If you pm me a copy of the driver I'll take a look at it if you want.


#3

Interesting... in all this fooling around, it didn't occur to me to add the GarageDoorControl capability to my driver along with the Switch and ContactSensor capabilities. Let me try that and see if I can make any progress first. If I can't figure that part out, I'll send over my driver. Much appreciated for the advice.


#4

I made some changes to my driver based on using the GarageDoorControl capability and did some testing, etc. It seems no matter what I do, when I use the Garage Control template on my dashboard tile, I receive the "are you sure" when I click on it, but nothing happens as far as triggering my relay.

It's my understanding (probably wrong) that clicking the dashboard tile when I'm using the Garage Control template, will call the open() or close() method in the driver if I'm using the GarageDoorControl capability - am I way off on that?

If I'm on my device screen and I click on the "open" or "close" button there, the relay triggers just fine.

Obviously I'm missing something :smile:

Thanks!


#5

Do you get any errors in the logs when you try to use the dashboard?


#6

Hey Ryan,

Sorry I've been busy and didn't have a chance to look. No, no errors... it's just like the dashboard tile using the Garage Control template just doesn't seem to trigger open() or close() methods in the driver for some reason.

Tonight just to test, I created a basic driver just to test this. It has only the GarageDoorControl capability and open() and close() methods. Then I created a virtual device using that driver.

When I view the device and click the open() or close() buttons, I get debug messages in the log as I should.

Then if I go and create a dashboard tile using the Garage (Control) template, and I click on it, I get the "are you sure" message, and I click "yes". I go and look in the log, and there is no debug message for triggering the open() or close() method in the driver. So odd, seems like a bug somewhere.

I'm not sure how to PM, but I'll find it and send you the driver I'm using for the test. Much appreciated buddy!


#7

That's because the driver you pmed me doesn't actually perform any functions. All it does is log what method gets called. And it only does that if you put certain comments on. You need to send me the actual driver you are using for the Shelly. You said you can open and close the door from the edit device page? Show me a screenshot of that page including the driver name.


#8

Ok, I finally today made some progress on this and everything seems to work properly.

I was digging around the internet and ran across a post about Hubduino device driver with parent/child drivers. One of the child drivers was for (child) Door Control. This driver ended up holding the key to allowing everything to work. I took the relevant bits from that driver and used them in mine, then I went to the dashboard and tried the button.... and.... it worked!! I have both momentary control of my Shelly 1 relay, and open/close status for the magnetic reed switch connected to it.

I should post the driver for everyone in case in can be useful, and I can probably do that shortly after I clean up a bit of the code.

Thanks everyone. Ryan780, I'll PM you what I've got.


#9

I wonder if your code could be used with the shelly 2.5 ?


#10

I'm sure it could, I don't see why not. The only thing I'm running into though, with MQTT on Hubitat, is that whenever I've got more than one device configured to use MQTT looking at the same broker, there seems to be some sort of conflict, where one device stops working and the other will work, or vice versa.

Today I installed another Shelly 1 to control a light switch and set up another custom driver for it. Everything worked well with the implementation and the light switch can be controlled via a Hubitat virtual device (via MQTT). The problem is, I went back to the aforementioned garage door control device and it no longer is working. I check MQTT via MQTT Explorer and the broker doesn't seem to be receiving the commands anymore.

I'm trying to troubleshoot the issue, but not sure what's going on. I'm going to look at the broker logs and see if I spot something.


#11

hmm I'm not having that issue. How are you running your broker ?


#12

I'm running Mosquitto on a Synology NAS. It crossed my mind there may be some configuration issue where connections are being limited, but in this case it would just be two connections, so that seems kind of ridiculous. I did see in the Hubitat log that one of the two devices had a "client disconnected" error when it attempted to initialize, and the other didn't, and the drivers are essentially the same.

I'm going to set up a separate Mosquitto instance on an Ubuntu VM I've got today and do some testing.


#13

I use a Rpi for my broker and no issues at all.


#14

Hey guys - I tracked down my issue, and as usual it was almost staring me in the face.

It was the MQTT connect() method in the driver. The second parameter is "clientId", which apparently needs to be unique. Mosquitto logs showed the first connection dropping when the second connection was being made - both with ID "hubitat", which is what I had been using in both drivers.

What I did to fix the issue was to make the string connectId specific to the driver and append the device.id to it. Here is the initialize method in one of the drivers, for example:

def initialize() {
    if (logEnable) runIn(900,logsOff)
    try {
        mqttbroker = "tcp://" + settings?.MQTTBroker + ":1883"
        interfaces.mqtt.connect(mqttbroker, "hubitat-garage-control-${device.id}", settings?.username,settings?.password)
        pauseExecution(1000)
        interfaces.mqtt.subscribe(settings?.topicSub)
        if (logEnable) log.debug "Subscribed to: ${settings?.topicSub}"
    } catch(e) {
        if (logEnable) log.debug "Initialize error: ${e.message}"
    }
}