Unavailable ("lwt") and Shelly

[uspino2]

Your plugin works great with 2 Shelly-1 acting as fully-closed and fully-open sensors, and one of them triggering the open/close pulse.

Now my only problem is Garage Door never appears as Unavailable, even when both Shellies go offline. I understand that's what "lwt" is there for, but any advice on how to use it with these devices? This is all the info on Shelly's API page:

Shelly1 MQTT
Shelly1 uses the following topics:

* shellies/shelly1-<deviceid>/relay/0 to report status: on or off
* shellies/shelly1-<deviceid>/relay/0/command accepts on, off or toggle and applies accordingly
* shellies/shelly1-<deviceid>/input/0 reports the state of the SW terminal
* shellies/shelly1-<deviceid>/longpush/0 reports longpush state as 0 or 1

And here's my config:

        {
            "accessory": "mqttgaragedoor",
            "name": "MQTT",
            "topics": {
                "statusSet": "shellies/shelly1-garage/relay/0/command",
                "closedGet": "shellies/shelly1-garage/input/0",
                "closedValue": "1",
                "openGet": "shellies/shelly2-garage/input/0",
                "openValue": "1"
            },
            "doorRunInSeconds": "10"
        },

Thanks!

[iomax]

The Shelly API docs show the last will topic and message as shellies/<shellymodel>-<deviceid>/online false I'd give it a try.

[uspino2]

Thanks for pointing that out. Hadn't seen this option. I added

            "lwt": "shellies/shelly1-garage/online",
            "lwtPayload": "false",

to my config and it does show as Unavailable in HomeKit after a few seconds unplugged.

Now one more thing. Are these values necessary?

"openStatusCmdTopic"
"openStatusCmd":
"closeStatusCmdTopic"
"closeStatusCmd": 

Not sure how they differ from closedget and openget. When the plugin comes back from Unavailable in HomeKit, it shows the right door status even without those values in config...

Anyway, thanks a lot, great work!

[iomax]

The plugin listen to the "closeget", as "openget" as well, topic to get the sensor state. open/closeStatusCmdTopic let the homekit app to ask update instead of just waiting for the sensor device broadcast. For example, shelly firmware by default announce the device state every 30sec. and "<close|open>StatusCmdTopic":"shellies/<shellymodel>-<deviceid>/update" should allow the home app to get the sensor state as needed ( e.g. at app startup )

[uspino2]

So in the case of Shellies (with 2 devices in my case), would this be the correct setting?

"openStatusCmdTopic": "shellies/shelly2-garage/update"
"closeStatusCmdTopic": "shellies/shelly1-garage/update"

What about "openStatusCmd" and "closeStatusCmd". Sorry, I don't see any clear info about it in the Shelly API docs. Thanks!

[iomax]

Yes it's not clear to me too anyway I'd try leaving it empty. Unfortunately I don't own any shelly where to try.

[uspino2]

I think I figured it out (again, for a system with two reeds, which is ideal). It's not particularly well explained at the API docs, but it's there. These are the right settings:

            "openStatusCmdTopic": "shellies/shelly2-garage/command",
            "openStatusCmd": "update",
            "closeStatusCmdTopic": "shellies/shelly1-garage/command",
            "closeStatusCmd": "update"

I can see your plugin correctly requesting an update to the broker at startup, so that must be it.

Again, great great work you did in here.

[iomax]

Good to know. Thanks for the feedback.

Please let me ask why is your config showing "doorRunInSeconds": "10", is your door so fast to complete the run in just 10sec ? if it is not the case, did you try with a value slight higher then real door run time ? It should trigger the obstruction state in the app if and when the door doesn't hit the open or closed sensor within the expected timeframe.

[uspino2]

There's an explanation for that: I took the Shellies and reeds off the gate to do all the testing without having to open and close the door 40 times before I got the config right :) But you are right: my sliding gate takes 23 seconds to open or close, and that's the value I'l be setting for doorRunInSeconds (maybe a couple of seconds more just in case the wind slows down the gate). That's actually one of the best things of this plugin: a very smart way to figure out potential obstructions thanks to doorRunInSeconds. For the price of 2 Shellies ($10 each) and 2 reeds ($3) we now get a really smart, solid and accurate HomeKit implementation, better than any other out there.

BTW, shouldn't your plugin be available through Config-UI X? I think it's too good to not be there!

[iomax]

OK, clear and yes, start the work in a "test-lab" environment is the right way to play with any new setup and safe to keep away several headache ;-).

Sorry, I did not were aware about Config-UI X but I'd think it'll based on npm packages or something like that and I didn't find time ( and pleasure ) to play with the packaging yet :-)