Create Binding for LaMetric #1704
Comments
|
Just found out, that an item can have multiple bindings connected. Thats awesome. With that I can make the inficator apps connecting via channel, which can directly be bound to items instead of having rules to control this. a push URL for an indicator app would look like this
So then the lametric binding could have an item config like the following
but what is a bit questionable is, the way to specify the id and configuration of the app. Unfortunately the ids cannot be looked up automatically. So so far I just see tags as an option... |
Not at all (as you found out already). You do not need any actions. Just add a String channel to your thing, which can then be used to pass messages to LaMetric.
Having to access HTTP requests is not really ideal and should be avoided. If there is no other way of getting hold of this information, though, you could register a servlet that processes these requests (and sends according updates for a trigger channel of your Thing). |
|
Thank you for the quick answer @kaikreuzer
This will be sufficient for simple text notifications without any additional configuration. However, a notification can have with the text
But then there are more interesting notification types like chart data where a series of data should be displayed. On the "indicator apps" level it is more complex, as they are defined partially customized by the user on the la metric device. One of the main issues I see is, that the ID of the app is not known and cannot be looked up. So there is no API to "discover" these channels and dynamically expose in OH. I see following variants for configuring such combinations. Variant A)
Variant B)
Variant B) would simplify the binding but making it harder for the user to configure. What variant would you suggest for "configurable channels" where also the number of channels is not known upfront and cannot be looked up.? |
|
Here some thoughts on how it could work. On the right the possibilities, LaMetric provides, on the left the way on how the binding could produce the notifications or map to indicator apps. Notifications Indicator Apps
Any feedback would be highly appreciated. |
|
Although I keep posting to myself, here the next evolution step of the concept. After headaches about how a tagging system could look I was not satisfied, and did a step back. I missed the most obvious thing. LaMetric Indicator Apps are actually just another style of a very limited UI. So why not create a sitemap to define them!?
Now there are 2 options for Indicator Apps on LaMetric I prefer b), but this requires to still map the items to a channel, so the binding will get updates and knows when to push. Alternatively a thread could periodically push data. Then we would not need a channel for the indicator apps. Also I would "abuse" the Frames label to map to an indicator app via id on LaMetric. Is this considered bad? Is there a cleaner way? Further I would mix UI Code (code dealing with sitemaps) and binding code (exposing channels) in one binding add-on. Is this ok, or would I have to split this? Thank you for any feedback! |
Sorry for that, you chose a bad timing - I am this week in full preparations for the openHAB 2 release, hence not able to follow-up on any binding related discussions; next week should be better again, thanks for your patience :-) |
Nothing to say sorry about. I'm not in a hurry and also did not expect answers from key people within that short time ;-) So I will keep posting to myself a while to record my thinking process on the topic :-D |
|
A couple weeks ago I started building a Java API for LaMetric Time. https://github.com/syphr42/liblametrictime-java It has a two-level API concept. At the low level are the local and cloud APIs. Then, stepping up one level I started building a more user-friendly API. I then connected it to OpenHAB 2 with a simple binding that does auto-discovery via UPnP and two simple channels (info and alert) to prove that it works. We should collaborate if you're interested. |
|
Hey Gregory! Looking at your code, it is definitely much cleaner and is also more complete on the LaMetric API Level then mine. I don't have the cloud version yet and no UPnP discovery. So I would rather take your base version to start an official binding than mine. The things to discuss:
|
|
Marco -
I love your enthusiasm! I agree with a lot of your ideas (some of them I
had been thinking about as well). I should have some time tonight and I'll
provide more thoughtful responses to each of your items.
On collaboration specifically, I think a mix of this issue as well as IRC
would be good for discussion. I'll try to get a channel set up on freenode.
As for the code, we should be able to use GitHub's mechanisms for
collaboration. I can probably just give you write access to my two
repositories if we're going to use my code as the base.
We can discuss more on logistics in IRC.
|
|
I would suggest https://gitter.im/ for chatting...
… Am 20.01.2017 um 17:24 schrieb Gregory Moyer ***@***.***>:
Marco -
I love your enthusiasm! I agree with a lot of your ideas (some of them I
had been thinking about as well). I should have some time tonight and I'll
provide more thoughtful responses to each of your items.
On collaboration specifically, I think a mix of this issue as well as IRC
would be good for discussion. I'll try to get a channel set up on freenode.
As for the code, we should be able to use GitHub's mechanisms for
collaboration. I can probably just give you write access to my two
repositories if we're going to use my code as the base.
We can discuss more on logistics in IRC.
On Jan 20, 2017 3:16 AM, "Marco Meyer" ***@***.***> wrote:
Hey Gregory!
Great news. Actually I just implemented the "same" thing locally in the
mean time. I pushed it now (although in a not working state) to be able to
exchange some ideas. You find it here:
https://github.com/reyem/openhab2-addons/tree/1704-LaMetricBinding
Looking at your code, it is definitely much cleaner and is also more
complete on the LaMetric API Level then mine. I don't have the cloud
version yet and no UPnP discovery. So I would rather take your base version
to start an official binding than mine. The things to discuss:
1.
I understand that you want to create the API in a separate project
without any OH dependency. Thats fine for me. But the way the dependency is
put into the binding ( jar file in the lib) looks dirty to me. However, it
looks like it is really the proposed way of OH2 dependencies. I'm neither a
OSGI nor a git pro. But do you see a way to:
a) make liblametrictime-java a proper OSGI dependency and deploy this
versioned into an OSGI repository?
or
b) somehow via git merge the liblametrictime-java with the add-on code,
so the code would be directly in the add-on as well? A quick googling
brought me this: https://git-scm.com/docs/git-submodule which looks
interesting, but I never used.
2.
Another issues I see is, that you are using jersey and jackson libraries
whereas OH, respectively ESH recommends to use the jetty http client and
GSON for those purposes (https://www.eclipse.org/smarthome/documentation/
development/bindings/dependencies.html
<https://www.eclipse.org/smarthome/documentation/development/bindings/dependencies.html>).
Although I'm not really concerned about the API ( well, I started liking
GSON and jetty for its simplicity compared to Jackson and jersey ;-) but I
can live with the others libs ), I wonder if it would not be better to use,
what OH already provides. I'm not aware of the real consequences and
potential conflicts.
3.
Your liblametrictime-java would need to be extended to be able to call
the REST API for indicator apps to be able to display open hab items as
described in my concept above. Did you have any thoughts about how to
expose it. I think you have already all the building blocks in the model.
So this should not be a big deal for the local calls at least. I think the
cloud calls would be more complex requiring additional keys per app and
OAUTH.
4.
Then I would be definitely curious on what you think about the concept
above for mapping sitemaps to lametric indicator apps?
5.
Did you have any thoughts about push apps? I currently only see a way to
expose an HTTP GET endpoint from the binding to be called. But I'm still
asking myself on what would be a good concept. The simplest thing would be
to just expose a URL like http://..../lametric/switches/[item-id]/toggle.
6.
and finally use cases. What I would like, but somehow seems not to be
possible is the following. OH gives an warning like "Garage Door still
open!". If I push a button, the Garage Door will be closed. But I think
there is nothing like this in LaMetric yet to be able to give feedback to a
notification via buttons!?
7.
Last but not least, how to best join forces?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<https://github.com/openhab/openhab2-addons/issues/1704#issuecomment-274005402>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAl8BKeVBNdMj4QlCpIQpDjaT6PGX57-ks5rUG1UgaJpZM4LjwEH>
.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I looked over the code you committed. It looks like we had a lot of similar ideas. I like where you're going with the channels. I haven't spent too much time investigating the apps yet for LaMetric Time, so I can't speak intelligently about how to support it yet. Regarding your list:
For items 4-6 I'm going to read over your earlier posts again and do a little research. I'll comment back after that. For collaboration, I connected gitter.im to the syphr42/liblametrictime-java repo to try it out. Good suggestion! It looks like it will be easier than IRC. I added a badge to the README.md with the link. I'm ok with using a different repo or even a different community name on Gitter if you like. I also invited you to collaborate on both repos (syphr42/liblametrictime-java and syphr42/openhab2-addons). We can discuss other options if you have a better idea. |
|
I'm not too keen on "reusing" the sitemaps to reproduce indicator app frames in LaMetric Time. I think it is a clever idea, but repurposing a core concept in a way the designers didn't intend in an app we can't control will probably lead to unexpected breakage and we will be playing catch up to keep the binding working. I'm not saying we can't go that route, but let's not go right to that without trying some other options first. So after some digging around in the ESH docs, I found something which might help us with indicator apps. In the things file you a user can define custom channels each with their own configuration properties. I think this might be worth pursuing as a proof of concept. We could create an indicator app channel type (rather than an actual channel) and let the user define the instances of that channel type. The user could define the app ID as well as the type of frame to send and then use rules to update the channel with the appropriate data. We could probably even create custom command types for each frame type. We will have to experiment to see what really works. |
|
When you asked about push apps, did you really me pull? Push isn't too hard because I think we can just use the widget update endpoint (see issue 4 that I created on the liblametrictime-java repo). For pull, things get difficult. ESH exposes a REST API that is very useful and easy to use. However, LaMetric forces the app creator to specify a URL ahead of time and that makes it very hard to support in an environment as dynamic as OH/ESH. The button apps will face the same problem. Button apps support only a single GET to a single URL defined at app creation time. As far as I can tell, there is no way to configure it at runtime or on the user's device (as far as the URL is concerned). If that is all true, our setup is terrible. I can envision an "openHAB" app on the LaMetric App store that is a button app. It does a GET against something like http://openhab-redirect.net/lametrictime/toggle and not only would our binding have to listen for a GET on "/lametrictime/toggle", but the user would have to configure a DNS server on the local network to handle the fake domain name. You could then hook that toggle to a channel update which would be configured by the user on a switch item and the rest is normal config. EDIT
|
|
I started playing around with the apps local endpoints. There is a lot of power in there. First off, you can get a list of the apps on the user's device. We could use this to populate custom channels. GET /api/v2/device/apps/ HTTP/1.1
Host: host
Authorization: Basic ...{
...
"com.lametric.countdown": {
"actions": {
"countdown.configure": {
"duration": {
"data_type": "int",
"name": "duration",
"required": false
},
"start_now": {
"data_type": "bool",
"name": "start_now",
"required": false
}
},
"countdown.pause": {},
"countdown.reset": {},
"countdown.start": {}
},
"package": "com.lametric.countdown",
"vendor": "LaMetric",
"version": "1.0.3",
"version_code": "9",
"widgets": {
"f03ea1ae1ae5f85b390b460f55ba8061": {
"index": -1,
"package": "com.lametric.countdown"
}
}
},
"com.lametric.radio": {
"actions": {
"radio.next": {},
"radio.play": {},
"radio.prev": {},
"radio.stop": {}
},
"package": "com.lametric.radio",
"vendor": "LaMetric",
"version": "1.0.10",
"version_code": "22",
"widgets": {
"589ed1b3fcdaa5180bf4848e55ba8061": {
"index": -1,
"package": "com.lametric.radio",
"settings": {
"_title": "Radio"
}
}
}
},
...
} |
|
First off, you can get a list of the apps on the user's device.
This is great news! I guess this is what the mobile apps call. So probably even control over the native apps can be taken. :-)
We could use this to populate custom channels.
I thought about channel per app as well. However, what item type would an app have, as finally we have to map item values to la metric "frames", which can even have multiple values, like the 'goal frame'. So either we need many channels per app or a complex tagging system. Thats, why I like the sitemap concept. But as it is possible to get a list of apps, maybe we should implement rather an OH bridge and expose apps as things with channels. The nice thing would be that this would also allow to dynamically expose new app-things at runtime.
When you asked about push apps, did you really me pull? Push isn't too hard because I think we can just use the widget update endpoint (see issue 4 that I created on the liblametrictime-java repo).
I meant push from OH to LaMetric exactly for the reasons you mention.
The button apps will face the same problem. Button apps support only a single GET to a single URL defined at app creation time. As far as I can tell, there is no way to configure it at runtime or on the user's device (as far as the URL is concerned). If that is all true, our setup is terrible.
Well, I was assuming a user can (has to) create an button app manually and put the local adress in the callback, before installing the app. I think it will be difficult to provide preconfigured apps on lametric for OH, as I understand these are meant for public web services. So in fact we would push OH items to a cloud app and all receivers get them on the device. But I think this use case is not so interesting for OH.
… Am 21.01.2017 um 03:31 schrieb Gregory Moyer ***@***.***>:
I started playing around with the apps local endpoints. There is a lot of power in there. First off, you can get a list of the apps on the user's device. We could use this to populate custom channels.
GET /api/v2/device/apps/ HTTP/1.1
Host: host
Authorization: Basic ...
{
...
"com.lametric.countdown": {
"actions": {
"countdown.configure": {
"duration": {
"data_type": "int",
"name": "duration",
"required": false
},
"start_now": {
"data_type": "bool",
"name": "start_now",
"required": false
}
},
"countdown.pause": {},
"countdown.reset": {},
"countdown.start": {}
},
"package": "com.lametric.countdown",
"vendor": "LaMetric",
"version": "1.0.3",
"version_code": "9",
"widgets": {
"f03ea1ae1ae5f85b390b460f55ba8061": {
"index": -1,
"package": "com.lametric.countdown"
}
}
},
"com.lametric.radio": {
"actions": {
"radio.next": {},
"radio.play": {},
"radio.prev": {},
"radio.stop": {}
},
"package": "com.lametric.radio",
"vendor": "LaMetric",
"version": "1.0.10",
"version_code": "22",
"widgets": {
"589ed1b3fcdaa5180bf4848e55ba8061": {
"index": -1,
"package": "com.lametric.radio",
"settings": {
"_title": "Radio"
}
}
}
},
...
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I played around with a custom indicator app. My conclusion is, that this is rather simple. You can post to the apps local url like to the notification channel. But the request body is just the frames array. Very interesting is, that it does not matter what frames you define in the app, when creating them. It accepts finally any number of frames of any type. Although I defined my app with 1 simple frame and one goal frame, I could finally send as well 2 simple frames and a spike frame...
So, a thing per app would definitely be overkill. Lets go back to one channel per app. Can we dynamically add channels, once the thing is added, or would we have to define a fix number of them to be configured?
Finally I still have no better idea on how to configure the channels and define items to be shown in the frames of an app channel. For me the sitemap stays the easiest for the user. Also I think the sitemap is actually for such purposes, although with lametric we cannot support the full complexity.
Pragmatic proposal:
- We predefine 5 indicator app channels.
- the channels can be configured with
+ appid
+ app-key
+ site-map name for the frames content
… Am 21.01.2017 um 03:31 schrieb Gregory Moyer ***@***.***>:
I started playing around with the apps local endpoints. There is a lot of power in there. First off, you can get a list of the apps on the user's device. We could use this to populate custom channels.
GET /api/v2/device/apps/ HTTP/1.1
Host: host
Authorization: Basic ...
{
...
"com.lametric.countdown": {
"actions": {
"countdown.configure": {
"duration": {
"data_type": "int",
"name": "duration",
"required": false
},
"start_now": {
"data_type": "bool",
"name": "start_now",
"required": false
}
},
"countdown.pause": {},
"countdown.reset": {},
"countdown.start": {}
},
"package": "com.lametric.countdown",
"vendor": "LaMetric",
"version": "1.0.3",
"version_code": "9",
"widgets": {
"f03ea1ae1ae5f85b390b460f55ba8061": {
"index": -1,
"package": "com.lametric.countdown"
}
}
},
"com.lametric.radio": {
"actions": {
"radio.next": {},
"radio.play": {},
"radio.prev": {},
"radio.stop": {}
},
"package": "com.lametric.radio",
"vendor": "LaMetric",
"version": "1.0.10",
"version_code": "22",
"widgets": {
"589ed1b3fcdaa5180bf4848e55ba8061": {
"index": -1,
"package": "com.lametric.radio",
"settings": {
"_title": "Radio"
}
}
}
},
...
}
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
Channels can be created dynamically in the code. There is a ChannelBuilder class to help. See this link to the documentation for more. I'm open to the idea of the sitemaps. I'd say let's give a shot and see how it turns out. Worst case we take another direction if it doesn't pan out well. |
|
Hi guys! At least I can be of help for testing if needed. |
|
Hey there... The project is still alive although we reached a state, where it satisfies our personal needs (at least mine) but was not ready to be contributed back. However, I guess in a few weeks we will hopefully make a pull request for making the binding official. For the mean time you can either checkout the branch on @syphr42 's repository: and build it yourself, or try if the prebuild jar which I attached here works for your openhab 2 installation: org.openhab.binding.lametrictime-2.0.0-SNAPSHOT.jar.zip Just rename the file by removing the .zip extension (I had to add it to be able to post it here) and put it in your OH2 addons directory. Then the device should be discovered by the add-on. Some documentation about the channels you find here: If you find any bugs or have improvement suggestions, please create issues in the @syphr42 repository for now. Thank you! |
|
On another note, in version 1.7.7 of the LaMetric Time firmware they corrected a bunch of typos in the API and raised the version number from 2.0.0 to 2.1.0. I have made the necessary changes in the in API library (https://github.com/syphr42/liblametrictime-java), but I haven't moved the new jar into the binding yet. This change removes support for API version 2.0.0 so all firmware versions prior to 1.7.7 are no longer supported. Since both the LaMetric Time device and its associated phone apps have been updated, there doesn't appear to be a reason to try to support the old API with bugs in it. |
|
Ok, thank you for the hint. I just updated to 1.7.7. It seems that the 'old' binding is still working with the new firmware. At least what I tested was
So I guess we can wait with the updated lib until we want to add the new channels for the native apps. |
|
@reyem
Of those, the only one that currently affects the binding is updating frames of an app. I'm confused that it is working for you. You should have gotten the following error in the openHAB log when you tried to update the indicator app: I was able to reproduce this on my local network with LaMetric Time running 1.7.7 just now. I also verified that with the new jar the error goes away and the app update is successful. I'm going to commit the new jar to the binding lib. If you need to access the old one, it is still in the Git repo. I haven't found any problems so far with the new jar, but please let me know if you encounter issues. @axberg |
|
FYI I created a new branch (https://github.com/syphr42/openhab2-addons/tree/1704-lametric-binding) with the binding code and updated the version to be in line with openHAB master. It is also rebased to the current version of master. Do not use the old branch - it will be deleted soon. |
|
Cool! I will start trying this out today or tomorrow and see if I find any issues or things I find missing. |
|
@syphr42, Thanks a lot for your work! I get an error when trying to communicate with the lametrictime, can you give me a hint what i'm doing wrong? I entered the Local Push URL from LaMetric Creators website as host in PaperUI but i get the following Error in the OpenHab Log: "java.net.URISyntaxException: Expected closing bracket for IPv6 address at index 15: https://[https://<my_Local_IP>:4343/api/v1/dev/widget/update/com.lametric.09f97c3001bd118d023522dd06111df2/1]:4343/api/v2" Where can I put this "closing bracket"? BR |
|
Rather than using the URL from the LaMetric dev portal for the app you created, you should be using the local IP or hostname of the LaMetric Time device on your network. For configuring your custom app so that you can push updates, you will need to define it as a "genericApp" thing. See more about configuration here: https://github.com/syphr42/openhab2-addons/tree/1704-lametric-binding/addons/binding/org.openhab.binding.lametrictime Also note that the structure of the binding has changed recently. The device is now configured as a bridge and apps are things that refer to the bridge. The bridge itself has channels for device control (e.g. notifications, bluetooth, display options, volume). The app things have there own channels specific to each thing (app) type. You will need to use the 'frames' channel on the 'genericApp' thing to push updates. |
|
Is there a way, you can put the current version of your binding in a prebuild jar file? I would love to use my LaMetric with openHAB2, but I am very new to openHAB (I used FHEM before) and not quite familiar with the building out of repositories. Thanks in advance! |
|
@syphr42: what do you think about a WIP PR? Thst would make the snapshot beiing built automatically and would be a goog first step before the final PR. |
|
I created a topic in the OH forum asking if submitting WIP PRs is acceptable. https://community.openhab.org/t/work-in-progress-pull-request/29585 |
|
It is, see all PR's starting with [WIP] |
|
The jar has been published here via the automatic build process: |
|
Thanks! I will try it as soon as I am at home! |
|
It works for me! Really nice job! Thank you so much! |
|
Thanks for a plugin for the lovely Lametric 👍 |
|
@overrunner : Hmm, according to this issue syphr42#2 |
|
@reyem yes, i grabbed it from the link 3 posts before. I am running it on openhab 2.1 stable. |
Closes openhab#1704 Also-by: Marco Meyer <marco.g.meyer@gmail.com> (github: reyem) Signed-off-by: Gregory Moyer <moyerg@syphr.com> (github: syphr42)
|
@overrunner : then try to install the missing bundle manually like described in the linked issue above. |
|
Hi! Should it work on OH2.2? I tried with this jar file: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.lametrictime/2.2.0-SNAPSHOT/org.openhab.binding.lametrictime-2.2.0-SNAPSHOT.jar |
|
The binding should work on 2.2-SNAPSHOT. I'll look into the problem. It may
be that dependencies changed in the platform.
|
|
Thank you, I will wait for a new version then and stop hacking around and destroying my installation. ;) |
|
This problem seems to be due to eclipse-archived/smarthome#4440. |
Closes openhab#1704 Also-by: Marco Meyer <marco.g.meyer@gmail.com> (github: reyem) Signed-off-by: Gregory Moyer <moyerg@syphr.com> (github: syphr42)
|
@OGR @kaikreuzer To remove the dependency on the internal package, I had to copy some of the internal classes in the LaMetric Time API. I pushed the new version up to the PR branch and tested it with the latest 2.2.0-SNAPSHOT docker image on Alpine and the binding is loading. |
Then you should have best used my second suggestion: "it might help if you add an upper version constraint of <2.4 to your com.google.gson.internal package import in the manifest." Copying the classes to the binding is definitely the worst option... |
Closes openhab#1704 Also-by: Marco Meyer <marco.g.meyer@gmail.com> (github: reyem) Signed-off-by: Gregory Moyer <moyerg@syphr.com> (github: syphr42)
|
FTR, I have done an initial review on https://github.com/openhab/openhab2-addons/pull/2345#pullrequestreview-85694216 and would suggest to continue all discussions on the PR. |
…#1704) Signed-off-by: Christoph Weitkamp <github@christophweitkamp.de>
LaMetric is a nice Display which can be used also for Home Automation to display status of items, show notifications or alarms, play sound via bluetooth speaker or send commands from LaMetric via button apps.
Product
http://lametric.com
REST API Doc
http://lametric-documentation.readthedocs.io/en/latest/
Concept:
A Home could have multiple LaMetric devices. So I see LaMetric as a thing with following channels:
To Display Notifications and Alarms via REST API, I guess it makes most sense to provide actions for rules and scripts. Also for send item status changes to "Indicator Apps" via REST API, actions would make sense. For receiving Key Presses from "Button Apps", the binding would have to expose some URLs. A Button App on LaMetric can call URLs via HTTP GET.
Any thoughts would be welcome. I started a local binding already, where I struggle with following questions:
The text was updated successfully, but these errors were encountered: