One thing I’m already missing though on the page, mentioned in my linked to above previous, is MQTT device_tracker
especially useful for auto-discovered automatic home/away statuses for Tiles, Nuts, iPhones, Apple Watches, AirPods, BM2 vehicles, Bosch Nyon **eBike computers and many other devices.
That’s what I meant with full HA MQTT discovery support for OH5 in my original post here
But it is definitely an improvement from the last time I tried it with the initial OH4 release, so I’kll give it another test run sometime soon.
Why weather forecast via mqtt? May be I am using not so many features but the open weather binding works very well for me …can you deep dive a little bit more what’s the issue here? @Spaceman_Spiff
@Hans_Lree but the device tracker than must sent information to mqtt and also have connections to the broker…but this could be easy if the device is in the same WLAN/LAN but when you have a “DS Lite” connection to the internet than it’s not that easy to handle this…but anyway you can easily implement this by your own with the birth topic and last will topic of mqtt, it what is the benefit or real new thing of it?
No, I am talking about a purely local Bluetooth device tracker, not a GPS one which requires cloud references. If the Bluetooth device is at home it will be registered as such and shown, be it an eBike with a Bosch Nyon bike computer, a car in the car port with a BM2 battery monitor, an iPhone, or an Apple Watch, as I am using with the extra unlocked property to set my alarm system when leaving the house and turning it off again when coming home, but only if I’m wearing it personally unlocked, and not if someone steals it and tries to turn off my alarm system at home
Sorry I wasn’t clearer about only really being interested in the local BT device_tracker earlier.
You can do this with my mobile and wifi connection using tr064 binding and as additional via an PHP script ( but honestly you don’t need the php script, it was my work around before the tr064 binding was released but I have never deleted) check if my mobile is connected to my wlan and as security feature I have to touch once my fingerprint sensor at home otherwise an alarm is triggered (this is just a paranoid thing maybe, because it feels a little bit of strange to go out the house without a key)…I am opening also my house door with this…I don’t have a key with anymore …
And the Bluetooth thing is implement as a script it pings my tracker and than show it up…
Have a look here:
So what is the benefit of the mqtt thing?
My experience is that the ble tracker is not so reliable than the WLAN connection checking
Also written here with a pro and cons about ble / Bluetooth Tracking
So it couldn’t track an Apple Watch, which is only connected to WiFi if it is not near my iPhone - not I suppose. And iPhones or iPads also wouldn’t be trackable via WiFi, as they go off the Wifi network when they sleep/go into standby.
I don’t see anything about the Bluetooth binding being able to track devices with randomly changing Bluetooth addresses, which all modern phones, watches etc. have. I can’t see anything about random Bluetooth MAC addresses on the page either.
Can it also pick up and show other properties of such devices, like the BM2 vehicle battery monitor, which a lot os users use to track the voltage and battery level of their car battery, at the same time using it as a home/away device tracker?
I’m sure you have a great setup for your particular phone, but none of that would work with my Apple Watch, iPhone, iPad ir BM2 battery monitor or anyone else’s such devices.
Presence detection via mobile connection is no walk in the park—especially with Bluetooth MAC addresses constantly changing. Sure, you can turn that off, but then privacy takes a hit. An alternative? Downloading a BLE beacon app. But beware: you’ll trade MAC stability for battery life.
On Android, it’s easier—I can ensure Wi-Fi stays connected even in sleep mode. iPhones? I can’t speak for those.
As for MQTT, you’re spot on: it needs a reliable connection to the broker, whether through Wi-Fi or LAN. Mobile internet works too, but good luck with DS-Lite/IPv6<>IPv4 issues when trying to access your broker.
In the end, it’s all a balancing act between privacy, effective tracking and battery drain/lifetime.
And the mqtt way you can already do by yourself with the last will topic and birth topic…
And luckily the same issues you will have with home assistant
I garbled that one. I’m interested in saving the current settings for the props (as set with Set Props in the Widget Developer UI). As an example, I have a thermostat widget with 9 props. Most of them take 6 or 7 clicks to set by navigating thru the model. that’s some 45 clicks every time I restart working on it. I’d be thrilled if I could keep my working set of those in a text doc and easily
There are two ways to do this now.
#1 is limiting if you have different things happening at different offsets #2 is intriguing. I need to buckle in and upgrade
I hear ya. It was a function I used a lot in my ISY99 days. Generally if I have two cases, I use two rules. Beyond that, I generally go for a script.
No, it is a walk in the park for iPhones, iPads, Apple Watches and AirPods/Beats Buds with our Theengs Gateway implementation, and it also is not possible to turn off randomised Bluetooth MAC addresses at all on these devices, which I find good for privacy and security reasons.
That is what I tried to introduce here almost a year ago when the then broken HA convention auto-discovery basically stopped me in the middle of my tracks. Home Assistant users, Jeedom users, FHEM users have been enjoying it for all this time now, and even myself on OH2 can easily implement it with Theengs Gateway by manually setting up the things and items, so hopefully once I get things tested and confirmed with OH 4.3 it will also be easily possible with auto-discovery for all openHAB users with such devices - as well as other non randomised ones and we can all happily walk in the park together
As I mentioned it’s possible if you have a reliable mqtt broker connection and not and issue with ipv6 to ipv4 and vice versa or DS lite…but nevertheless I don’t want to fight
I don’t think that’s a reason, but this shouldn’t the discussed here but rather between us developers/maintainers on GitHub. @maniac103 Can you please ping me in an Android app issue where we can have a look at this?
I’ve had two meters and sml2mqtt identifies the meters by serial number so it doesn’t matter which reader I place on which meter and which usb device gets discovered first on startup (both are the same device so the usb enumeration varies).
Additionally it can do complex processing and filtering which means I don’t pollute the event bus as much (sml reports multiple values every second) and multiple complex rules become a simple configuration entry in sml2mqtt.
It’s not a big move, that’s why I wrote “in my small bubble”.
I’m not using the weather forecast through MQTT - that’s a misunderstanding.
I’m running HABApp and am querying the rest api of the weather service in a python rule.
Then I post the complete validated response to the HABApp event bus.
That way it’s way easier e.g. to find the max temperature forecasted for today because I don’t have to deal with hundreds of items and can programmatically iterate through the forecast.
It’s basically a processing pipeline which t makes it easier to pick appropriate defaults in case the weather service goes down and simplifies the logic done in each step.
I am currently working with Quarkus and AFAIK (I have also searched the web) neither Quarkus nor Spring provide the modularity that OSGi provides and openHAB uses.
Quarkus emphasises the microservice approach where you have several independent services in a containerised (cloud) environment.
OSGi in contrast allows building modular Java applications that run in a single application.
From an architecture POV Karaf (OSGi) is much more suited for openHAB than the microservice approach of Quarkus.
Now to GraalVM native compilation: GraalVM native images are highly static, which is great for a microservice architecture, but doesn’t fit the highly modular approach of OSGi. Compiling a modular OSGi application to a native image (if possible to, which at least is a ton of work and probably impossible without a huge effort) would make it loose it’s modularity, which is quite contrary to the reason you choose OSGi: runtime modularity.
Also keep in mind that not all applications benefit from native images: Whilst this reduces statup time and memory footprint, runtime performance, runtime performance like peak throughput and decreases often. This is because the AOT compilation of native image isn’t able to optimise the code dynamically at runtime, which the JVM‘s JIT compilation is able to. JVM applications often need a „warmup“ time to achieve their best performance, openHAB as a long running application suits for that.
Horizontally scalability: I wonder for what we need this.
We are in home automation, and not in a containerised cloud environment. Other smart home serves (e.g. Gira Home and Gira Facility KNX servers, the latter targeting big facility buildings) scale vertically, and I cannot really imagine anyone having such a big building where he wants to run a single openHAB instance that cannot run on a machine.
You can either connect multiple openHAB instances or run on beefier hardware than a Pi 5.
@tcgerhard
You can do this for a long time with the timeline picker. You must define ONE Channel in Astro binding and can uses this channel for ALL Timeline pickers in Your system. For each representation is it possible to define own offsets and in addition you can create dynamic solutions. One time installed all changes are made in your widget of timeline picker.
