binderth
October 19, 2020, 11:40am
1
As I’m playing around a bit with openHAB3 M1, I did come across some bindings, I’d like to use with OH3 also - and as the polling in Poll: Which OH1.x addons do you use? was something I missed, perhaps someone has an idea for the following I use:
I know, there’s some discussion around
is there a chance to use these with OH3?
rossko57
October 19, 2020, 11:44am
3
Have another look around for this. While there are grand plans for OH3, the OH2 version is useable under OH3.
Update: Complete rewrite to use the rule templates published to the Marketplace. There is no need to code this or copy/paste code to make this work.
There is a Remote openHAB binding which replaces this capability in most cases. See openhab-addons/bundles/org.openhab.binding.remoteopenhab at main · openhab/openhab-addons · GitHub . However there may be use cases where MQTT is preferred, such as integration with a non-openHAB service.
binderth:
Likewise, another look around
As some of you might know the http binding is still an openHAB 1-addon and will not be supported in the upcoming openHAB3. Therefore I developed a new openHAB 3-version. This is still work-in-progress, but I would like to here your thoughts (especially on missing or unclear features), bugs and everything related.
The documentation can be found on Github: (edited: binding included in distribution).http and the latest and greatest JAR is available at (edited; binding included in distribution).
Y…
binderth:
I do not think any ‘native’ solution is ready, however this is available now
Edit: I’ve reimplemented this and am hosting it on my own repo instead of as a submission to the helper libraries.
As a challenge to myself I wanted to see if I could replace the Expire binding using Rules. The answer appears to be yes.
See https://github.com/rkoshak/openhab-rules-tools for a drop in replacement to the Expire binding. You don’t even need to change your Item configs. The rules will pick up your existing Expire binding configs and use them.
The only limitation is you must caus…
1 Like
binderth
October 19, 2020, 11:55am
4
for example: I saw, ekey was not voted on (but I do know, there are a bunch of users here in the forum besides me) and if it says “supported”, it’s worked on for OH3? that would be fabulous!
binderth:
expire
@kai is working on a solution for that, I believe. Personally I am experimenting with moving to HABApp which can have similar functionality.
opened 07:21PM - 03 Sep 20 UTC
closed 01:15PM - 19 Nov 20 UTC
work in progress
Since openHAB 1.x bindings are incompatible with openHAB 3 and there is a substa… ntial user base that has the 1.x expire binding in use, we should introduce a replacement for this functionality.
https://github.com/openhab/openhab-core/pull/744 was a first try to do so, but doing it as a profile has too many constraints.
As commented in https://github.com/openhab/openhab-core/pull/744#issuecomment-485055862, my suggestion would be to natively support the functionality in the core framework, similar to [the "autoupdate"](https://www.openhab.org/docs/configuration/items.html#parameter-autoupdate). This would essentially also mean that item files of users stay fully compatible as the configuration could just be like:
```
Number Temperature "Temp [%.1f °C]" { expire="1h" }
```
Internally, this will just be a metadata provider with a specific namespace ("expire"), so reading and writing this information would directly be possible through the existing REST API as well.
@openhab/core-maintainers Would that make sense to you?
@ghys Is this something that could also be easily supported by the UI then? The most tricky part is probably the syntax of the expire configuration, but if that isn't a big issue to parse, I'd tend to stick to it for compatibility reasons.
1 Like
rlkoshak
October 19, 2020, 3:43pm
7
A native version of both Expire (part of core) and the Event Bus (will be a separate plugin) are in work for OH 3. I can’t say where they are in terms of implementation but I think there has been activity on both.
1 Like
