Create Binding for LaMetric

[reyem]

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:

• Audio ( change volume )
• Bluetooth ( switch on/off, change name )
• Display ( change brightness )

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:

• How to best address "things" from actions. As there could be multiple devices, how to say to which device the notification should be sent.
• How to best expose buttons via HTTP GET? Or could this be achieved via existing OpenHab REST API?
• Could it make sense to expose Notifications somehow via channel? What type? Possiblities I see is "nr of notifications" : number, and "last notification" : text...

[reyem]

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

https://developer.lametric.com/api/V1/dev/widget/update/com.lametric.3539cd1562f031ed25fd287c7ddf2b34

So then the lametric binding could have an item config like the following

Number Weather_Temperature "Outside Temperature [%.1f °C]" <temperature> (Weather, Weather_Chart) [ "lametric:3539cd1562f031ed25fd287c7ddf2b34", "lametric:frame1" ] { channel="yahooweather:weather:berlin:temperature", channel="lametric:indicatorapp..." }

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...

[kaikreuzer]

How to best address "things" from actions. As there could be multiple devices, how to say to which device the notification should be sent.

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.

How to best expose buttons via HTTP GET? Or could this be achieved via existing OpenHab REST API?

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).

[reyem]

Thank you for the quick answer @kaikreuzer

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.

This will be sufficient for simple text notifications without any additional configuration. However, a notification can have with the text

• an icon => theoretically the items icon could be used or a tag
• sound with optional ( it is just a text id of the sound to play, with optional repeat number and a category [alarm or notification] ) => tag as well?

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. Thinking about it, theoretically a user would need to be able to add channels manually, setting up the desired combinations for his needs.

I see following variants for configuring such combinations.

Variant A)

1. Provide a set of standard channels ( simple notification channel, alarm channel ... ) on the LaMetricDeviceThing thing for easy use but limited functionality. The channels could allow configuration on thing level as well.
2. introduce a LaMetricAppThing for the indicator and potential button apps. That way, one could configure things like the app ID and additional configuration setting in the things configuration. The thing would just expose one channel though and need to be linked somehow to a LaMetricDeviceThing.

Variant B) Go via tags: 1) define an item group using a tag like [lametric:appid] for identifying the the indicator app 2) define items in the group for the individual frames in the group using a tag like [lametric:frame#1] to identify in which frame to display the items value. 3) for notifications also use tags to define sound id, etc. 4) additonal tags would potentially be required for icon, cycles ( how long/often to display a notification)

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.? Or maybe I miss or misunderstand a concept completely?

[reyem]

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 The basic idea is to expose 3 standard notification channels for the available priorities info, warning and critical. They would just support simple text messages, as I think it makes little sense to send a chart as an alert. All things like icon, sound etc. would be configured in the thing config. If still more flexibility is required there would be a jSON Notification channel where the raw JSON structure can be sent via text item which would allow full flexibility.

Indicator Apps Here the idea is to put all the items which should be updated in indicator apps into a group. The group would have a tag with the app id. Each item is bound to the indicator app channel. Additional tags might be introduced to specify the icon id to be used, or if instead of text the chart should be shown. The text to transmit will actually be the item label.

Any feedback would be highly appreciated.

[reyem]

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!? So basically the binding configuration would name a sitemap. The sitemap would define Frames as container for multiple indicator apps, having a label with the app id. Within the frame there are just three types possible:

• Text which maps to Simple
• SetPoint which maps to Goal
• Chart which maps to Chart

Now there are 2 options for Indicator Apps on LaMetric a) Polling: LaMetric periodically polls for the new app data b) Push: The binding pushes data updates to 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. @kaikreuzer or any other experienced OH/ESH engineer. What would be preferred from the OH Architectures point of view? a) Expose an HTTP Endpoint which is periodically polled for updates b) Have updates pushed via channel update c) Schedule a periodic task to update the device

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!

[kaikreuzer]

Although I keep posting to myself

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 :-)

[reyem]

Sorry for that,

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 Good luck for the release!

[syphr42]

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.

https://github.com/syphr42/openhab2-addons/tree/feature-lametrictime/addons/binding/org.openhab.binding.lametrictime

We should collaborate if you're interested.

[reyem]

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). 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?

[syphr42]

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.

[reyem]

I would suggest https://gitter.im/ for chatting...

Am 20.01.2017 um 17:24 schrieb Gregory Moyer notifications@github.com:

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" notifications@github.com 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.

[syphr42]

@reyem

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:

1. I agree that dropping the jar in a lib folder is messy. I tried to use Maven until I realized that Maven is not how dependencies are managed in Eclipse-based projects like this. I searched around for a better solution, but all I found without significant additional work was this. I am building the library with the Maven bundle plugin from the Apache Felix project so it has OSGi entries in the manifest. The real problem is getting it into the Eclipse ecosystem (and into Orbit). This looks like a relatively big bureaucratic undertaking and I didn't want to slow down development. I do want to keep the library separate so it can go into Maven Central and be generally useful outside of OH/ESH. I'm willing to brainstorm on this some more to try to make it nicer.
2. I'm fine with converting to Jetty and Gson. I started the library before I started working on OH and I just used the tools I already knew. I've got no special attachment to Jersey and Jackson. I always like to use standard APIs as much as possible (e.g. JAX-RS and JAXB), but JAXB for Json was clunky when I used it in the past.
3. I created an issue against the liblametrictime-java repo for implementing the app endpoints. I want to make the API as feature-complete as possible so I'm onboard for adding it. I would like to have the low-level API stick to the LaMetric Json model as closely as possible, but the higher level API should be whatever is most natural and easiest to use. We can discuss ideas. I just started the high level API so I'm not tied to anything. I do plan on implementing the OAuth elements needed to access secured parts of the cloud API. To start it can be as simple as the user has to perform the OAuth bits and then drop the tokens in. It would be great if it could progress to performing the full OAuth, but I'm not sure that is possible with the way the redirect URL is defined in the developer portal.

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.

[syphr42]

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.

Channels Documentation

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.

[syphr42]

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 was poking around on GitHub to see how other projects are integrating with LaMetric Time. Some have taken the approach of making a URL available and simply instructing users to go to developer.lametric.com and make their own private app and enter the URL of the local server. I suppose this is an option as well, though certainly not as user-friendly. If we went this route, we have the two options Kai pointed out in this thread.

1. Implement a binding in which you register a servlet that deals with the specific GET calls from your external system
2. If you do not want to do any coding, you could consider to re-(mis-)use the CMD servlet of the ClassicUI, which accepts GET requests to set states like e.g. http://demo.openhab.org:8080/classicui/CMD?Weather_Temperture=2.

[syphr42]

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"
        }
      }
    }
  },
  ...
}

[reyem]

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 notifications@github.com:

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.

[reyem]

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 notifications@github.com:

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.

[syphr42]

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.

[axberg]

Hi guys! How's this going? Are you still working on this? I also have a LaMetric device and would really like this kind of addon. Maybe I can help some. Not too familiar programming Java for openhab but got plenty of experience in the MS universe..

At least I can be of help for testing if needed.

[reyem]

Hey there... Nice to know the community of LaMetric users in the openhab world is larger than 2 :-)

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: https://github.com/syphr42/openhab2-addons/tree/1704-lametric-binding

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:

https://github.com/syphr42/openhab2-addons/tree/1704-lametric-binding/addons/binding/org.openhab.binding.lametrictime

If you find any bugs or have improvement suggestions, please create issues in the @syphr42 repository for now. Thank you!

[syphr42]

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.

[reyem]

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

• brightness channel
• info notification channel
• indicator app channel

So I guess we can wait with the updated lib until we want to add the new channels for the native apps.

[syphr42]

@reyem The following local API calls would fail with the old library after upgrading the device to 1.7.7:

• Getting a specific notification by ID
• Dismissing (deleting) a specific notification by ID
• Updating frames of an app
• Executing an action in an app

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:

java.lang.IllegalStateException: Illegal character ":" at position 23 is not allowed as a start of a name in a path template "/api/v2/widget/update/{:id}".

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 Additionally, please be aware that the binding is still using the 2.0.0 version number because we have not resynced to the latest master. Before we submit the PR we will need to update to 2.1.0. This is just an FYI in case you are wondering why the version number is behind.

[syphr42]

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.

[axberg]

Cool! I will start trying this out today or tomorrow and see if I find any issues or things I find missing. I'm sure there would be more people interested in this if it was released as an official binding and listed together with all other bindings.

[Turb0fan]

@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://:4343/api/v1/dev/widget/update/com.lametric.09f97c3001bd118d023522dd06111df2/1]:4343/api/v2"

Where can I put this "closing bracket"? Thanks in advance for your support.

BR

[syphr42]

@Turb0fan

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.

[cainearized]

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! Sven

[reyem]

@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.

[syphr42]

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

[martinvw]

It is, see all PR's starting with [WIP]

[syphr42]

@cainearized

The jar has been published here via the automatic build process: https://openhab.jfrog.io/openhab/libs-pullrequest-local/org/openhab/binding/org.openhab.binding.lametrictime/2.1.0-SNAPSHOT/org.openhab.binding.lametrictime-2.1.0-SNAPSHOT.jar

[cainearized]

Thanks! I will try it as soon as I am at home!

[cainearized]

It works for me! Really nice job! Thank you so much!

[overrunner]

Thanks for a plugin for the lovely Lametric 👍 Can someone help me with the gson error? Unresolved requirement: Import-Package: com.eclipsesource.jaxrs.provider.gson

[reyem]

@overrunner : Hmm, according to this issue https://github.com/syphr42/openhab2-addons/issues/2 It should be fixes. Did you install the latest snapshot?

[overrunner]

@reyem yes, i grabbed it from the link 3 posts before. I am running it on openhab 2.1 stable.

[reyem]

@overrunner : then try to install the missing bundle manually like described in the linked issue above.

[OGR]

Hi! When I try this binding on my OH 2.2 snapshot it just throws this error: “Unresolved requirement: Import-Package: com.google.gson.internal”

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

[syphr42]

The binding should work on 2.2-SNAPSHOT. I'll look into the problem. It may be that dependencies changed in the platform.

[OGR]

Thank you, I will wait for a new version then and stop hacking around and destroying my installation. ;)

[kaikreuzer]

This problem seems to be due to https://github.com/eclipse/smarthome/issues/4440. To solve it, it might help if you add an upper version constraint of <2.4 to your com.google.gson.internal package import in the manifest. The even cleaner way would be to not rely on packages that have "internal" in their name at all :-)

[syphr42]

@OGR @kaikreuzer The problem here is that the LaMetric Time API makes use of custom type adapters with Gson and to do that it uses the 'extras' code from the Gson repository (https://github.com/google/gson/tree/master/extras). This code references the 'internal' package of Gson.

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.

[kaikreuzer]

This code references the 'internal' package of Gson.

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...

[kaikreuzer]

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.