openHAB Integration

openhab
client-apps
integration
home-automation
Tags: #<Tag:0x00007fe88cbf6770> #<Tag:0x00007fe88cbf6630> #<Tag:0x00007fe88cbf64f0> #<Tag:0x00007fe88cbf63b0>

#3

Second Ping : Can someone post the sitemap that was used for the layout of the controls shown in the screen capture?


#4

There isn’t actually a sitemap to go with the screenshot; the client is just rendering the UI group item based on the example items file.

If you come up with a nicer rendering based on a sitemap, please add it to the wiki page!


#5

I’m confused. Then how exactly did the UI render them? I’m not aware of any way to render in the app directly from an items file…

What were you using to get the screen shot?


#6

Sorry; I could have been clearer. If your sitemap has

Group item=UI

then you will be able to navigate into the group and the items will be rendered per the screenshot.


#7

The new link for the Garadget binding for openHAB is:

http://docs.openhab.org/addons/bindings/garadget1/readme.html


#8

Thanks, updated the links.


#9

Looks like openHAB now supports MQTT. Anybody had a chance to try out a direct integration with Garadget’s over the LAN? Please report.


#10

openHAB has supported MQTT for years with its MQTT 1.x binding which still works perfectly in the latest openHAB, and Garadget’s MQTT support has worked with openHAB since the firmware update that added MQTT.

The 2.x MQTT binding offers features that only help if your device follows a topic naming and type convention, which is probably very rare in the wild and does not apply to Garadget. So you end up doing a lot of manual configuration, which in the end looks to be more complicated than the MQTT 1.x binding configuration, to my reading.

openHAB’s 2.x binding architecture often complicates various IoT and smarthome configuration tasks from the simpler 1.x model that has no auto-discovery and is configured in text files. Even though it was intended to add autodiscovery and a config UI, some 2.x bindings end up introducing yet more complexity and issues to be aware of and needing to be worked around. Under ideal circumstances, they make life easier, but in my experience most DIY smarthome automation is not under ideal circumstances. I think a few openHAB 2.x bindings were built to prove that it could be done to match the new binding architecture, and not necessarily to make it easier to use in real world use cases.

John


#11

John,
Thanks for chiming in. I’ll look into the specs for 2.x MQTT binding to see if Garadget’s can be modified to support the auto-discovery and config.

Do you by any chance have a sample openHAB config you can share using Garadget with MQTT 1.x implementation?


#12

I continued using the Garadget binding I wrote using the Particle API because, even though it polls, there was no real need to have faster updates than the polling cycle, and there was a real need to have encrypted MQTT to my public broker. That being said, it’s very easy to give you a configuration for both the Garadget binding and the MQTT 1.x binding and I’ll send those over in a bit.

John


#13

Complete configuration for openHAB using either the MQTT 1.x or Garadget 1.x bindings. If you had both transports set up in your Garadget, you could have both paths set up to control your Garadget, in case the Particle Cloud failed, for example.

Denis, please don’t incompatibly change the topics that the Garadget subscribes and publishes to!

Thanks,
John

items/garadget-binding.items:

// Using the Garadget binding and Particle REST API:
// The only thing to change for your setup is 330048000XXXXXXXXXX13337

String name               "Garage Door [%s]"   <rollershutter> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#name]" }
String doorStatus_status  "Status [%s]"           <garagedoor> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#doorStatus_status]" }
String doorStatus_time    "Last Change [%s ago]"       <clock> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#doorStatus_time]" }

// Send the doorState item commands like ZERO, HUNDRED, UP, DOWN, ON, OFF, STOP, or "open", "close" or "stop".
Rollershutter doorState   "Control"            <rollershutter> (MainDoor) { garadget=">[330048000XXXXXXXXXX13337#setState],<[330048000147343
433313337#doorStatus_status]" }
Number doorStatus_sensor  "Reflection [%d %%]"           <sun> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#doorStatus_sensor]" }
Number doorConfig_srt     "Threshold [%d %%]"        <battery> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#doorConfig_srt]" }
Number doorStatus_signal  "Signal [%d dB]"           <battery> (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#doorStatus_signal]" }
Switch connected          "Connected [%s]"                     (MainDoor) { garadget="<[330048000XXXXXXXXXX13337#connected]" }

items/mqtt-1x-binding.items:

// Using the MQTT 1.x binding:
// The only thing to change for your setup is Home

String doorStatus_status  "Status [%s]"           <garagedoor> (MainDoor) { mqtt="<[broker:garadget/Home/status:state:JSONPATH($.status)]" }
String doorStatus_time    "Last Change [%s ago]"       <clock> (MainDoor) { mqtt="<[broker:garadget/Home/status:state:JSONPATH($.time)]" }

Switch getConfig          "Get Config"                         (MainDoor) { mqtt=">[broker:garadget/Home/command:command:*:get-config" }
Switch getStatus          "Get Status"                         (MainDoor) { mqtt=">[broker:garadget/Home/command:command:*:get-status" }

// Send the doorState item commands like ZERO, HUNDRED, UP, DOWN, ON, OFF, STOP, or "open", "close" or "stop".
Rollershutter doorState   "Control"            <rollershutter> (MainDoor) { mqtt=">[broker:garadget/Home/command:command:*:MAP(garadget.map)],<[broker:garadget/Home/status:state:MAP(garadget.map)]" }
Number doorStatus_sensor  "Reflection [%d %%]"           <sun> (MainDoor) { mqtt="<[broker:garadget/Home/status:state:JSONPATH($.sensor)]" }
Number doorConfig_srt     "Threshold [%d %%]"        <battery> (MainDoor) { mqtt="<[broker:garadget/Home/config:state:JSONPATH($.srt)]" }
Number doorStatus_signal  "Signal [%d dB]"           <battery> (MainDoor) { mqtt="<[broker:garadget/Home/status:state:JSONPATH($.sensor)]" }

transform/garadget.map:

open=UP
close=DOWN
stop=STOP
ON=open
UP=open
0=open
OFF=close
DOWN=close
100=close
STOP=stopped

services/mqtt.cfg example (if using MQTT broker on standard port on mqttbroker.local machine):

broker.url=tcp://mqttbroker.local:1883

services/garadget.cfg (if using the Garadget binding):

username=your@email.com
password=yourpassword

#14

Awesome! Thanks, John!


#15

Hi gentlemen, - first of all a happy new year. May I ask for your support. I am trying hard to get GARADGET BINDING working in my recent openHAB 2.4.0 setup. But I need to get some more support, as I cannot get it working properly. What I did as by now …

SET UP GARADGET BINDING in paper UI; username and pw are set up correctly (as I would use them in; https://www.garadget.com/my/settings.php?id=3900xxxxxxxxxxxxxxxxxxxx34xx)

Build GARADGET.ITEMS;

Group Garadget
Group UI

// String name “Garage Door [%s]” (Garadget,UI) { garadget="<[3900xxxxxxxxxxxxxxxxxxxx34xx#name]" }

Check; if I could read correct name in SITEMAP;

Frame label=“Garage” {
Group item=Garadget {
Text item=name
}
}

But I cannot get any device info visible in sitemap.


#16

With the // on the line

// String name “Garage Door [%s]” (Garadget,UI) { garadget="<[3900xxxxxxxxxxxxxxxxxxxx34xx#name]" }

you have “commented out” the item definition, which means that that line is being treated as a comment in the file instead of having an effect. If you remove the // at the beginning of the line, the you will have then actually defined an item named name that is attempting to retrieve the name of the garage door from the Particle API.


#17

Hi,

thanks for your feedback. Yes, that was a typo in my example made in hurry (I am aware, that it becomes a phrase comment than , as I am using Visual Studio Code it is also visible :slight_smile: ). Unfortunatelly item definition >name< is not sending back correct “name” of door from particle API (or any other value). How can I check, if particle API is working correctly? If I do open https://garag.io/my/settings.php?id=3900xxxxxxxxxxxxxxxxxxxx34xx it is showing a blank page only. Garadget device number I received via https://www.garadget.com/my/settings.php?id=3900xxxxxxxxxxxxxxxxxxxx34xx - and here everything is shown fine?!

Do I have to “unlock” that API site at garag.io for my device first, maybe? I am struggling here …

[BTW: GARADGET FW is 1.20]


#18

Your .items file has lowercase .items name extension, lives in provided items directory, similar rules for .sitemap file, your UI references your sitemap. Turn on debug logging and see what gets logged?


#19

Let me send some pictures to explain current status in a better way …


My setting on garadget.com:

and same on https://garag.io/my/settings.php?id=:

LOG:

2019-01-05 15:38:44.284 [WARN ] [ng.garadget.internal.GaradgetBinding] - Unable to poll variables for deviceId 39xxxxxxxxxxxxxx; skipping.


#20

:astonished: oh boy … how stupic can I be ?!
What went wrong: It is a good idea to use the correct EMAIL ADRESS in the binding !! Man !!

Thanks a lot for your help …!


#21

Hi John,

would you mind to share your sitemap configuration, how you achieved such a clean overview as shown on https://github.com/openhab/openhab1-addons/wiki/Garadget-Binding ?


#22

Glad you got the config sorted out!

I think the example items are similar to here, and since all items were in the UI group, I had simply navigated into that group using the Classic UI and taken the screenshot there. In other words, this was the default item rendering for the items defined in the items file.