In general, I think the health check is a really great feature that still has potential. I could also imagine that you could see all bindings that contain things that are offline or rules that throw errors in a collected and structured way. It would make it a little easier to identify the causes of errors in complex installations.
What‘s wrong with the ThingStatusReporter?
It does exactly what you want.
It would be fine, if there would be a weather binding, without needing openweatermap api. I moved openweathermap out from my system, as they changed to their new model, where after a count of requests you have to pay, and the need a credit card… No way for me.
Now i am using openmeteo which works fine, even without the special binding, just need the http binding to make http requests and filter out the needed information.
But ALL weather widgets I found, are using openweathermap…
Kind regards,
Thomas
Are you looking for a widget or a binding ?
We have some other weather bindings…
The weather widget can be used with other bindings, you just need to have the items created the widget needs.
I’m looking for a widget. I have already requested the items via the openmeteo API via http request…
I already thought that I could adapt a widget by simply storing my items… with openweathermap, a lot of the preparatory work has already been done because you already have finished item files that match the widget.
If you already have the OWM items, just relink them to the channels you get the information from…
That’s all you need to do.
Yes, that will be the way I think…
Please open a new topic and we can discuss it there.
Thread is already so long, I hope I am not creating a double entry…
Lots of topics are about additionally supporting this or that hardware, also stating that they are available in this or that other home automation project.
Today volunteers create in parallel ‘drivers’ for FHEM, OpenHAB, HA, … → isn’t this a waste of precious time to develop things three times in a different programming model? Of course you can use each time an own docker container (especially for more exotic hardware, RTL_433, EUFY RoboVac, Polestar car,…) and integrate them somehow (MQTT), but there is still room…
Why not just have a dedicated workstream, sitting together with the others frameworks and over time try to converge to a neutral adapter implementation programming model? I know, there is GO, Python, JS, Event-Driven → so it is very tough. But just imagine there is only ONE driver implementation instantly available for ALL platforms (FHEM, OpenHAB, HA, …)? That would boost the eco-system developer motivation (also for more exotic hardware) and boost home-automation adoption for not-so-much-experts…
No, it isn‘t, as all system you mentioned are completely different structured unde the hood, that your suggestion would need a major refactoring of the core…
Edit: But the upcoming Matter support will make things a lot easier….
Christmas is coming closer, so I wish me better/mature support of external JS within oh-widgets.
Details: openHAB 4.3 feature request: support of external JS within oh-widgets
Best regards, O.
@hmerk I completely agree, I was just wondering if maybe a joined roadmap between the ‘big players’ could make sense with the aim to have a better interoperability in let’s say 5 years? And then there could be small steps here and there to reach this ambitious goal like aligned property names, aligned events, aligned authorization concepts, … → this could reduce step by step the porting effort. But maybe already Matter could be a help in the future.
What I would like to see is some Integrated Timer Possibilities. Like beeing Able to adjust times easy on the GUI. For Example for an Alarm Clock, Raising Blinds or trigger other Activities at certain times. Solved that for now with the Time Picker, but to have that integrated would be nice.
I thought of a Thing simulation mode. I don’t know if this is a bright idea or a false good idea.
We could have three values :
- timing,
** channel
** state
or
** status and status detail
for any given number of occurences and the thing would either play it sequencially respecting the timing or in burst.
I saw some interests for simulation or tests
I don’t think this is hard to develop but would like feed-back regarding potential interests, or maybe even there already exists a way to do it. I know we can do a part of this using persistence but it only target Items, not channels (this puts apart events, profiles…)
i really want you to be right, i truly do. But I expect matter to become something similar to zwave vs zigbee if zigbee had never existed…
Relevant because it is actually good, but the expensive certification will limit its adoption because it makes all devices more expensive than their counterparts.
E.g.: why buy any matter bulb when a zigbee one is dirt cheap?
I say this and yet I really want to eat my words..
Another wish!
I know how to use the Astro binding to start automations when the Sun rises or sets, but I want something different - I want a rule that runs after Sun set and before the Sun rises . So night time only.
Node red has something called “big Sun” which is super cool, where we can catch all of the different day periods and we can do “from Sun set to Sun rise → if front door is opened → turn on the light”
I don’t think we can do this in openHAB in an “easy” way today, at least the Astro binding doesn’t look to be right way.
My mind wants to say “during” instead of “START” or “END”…
So I was thinking of a pick option where we could select “day/night” for starters and maybe add some logical constraints or offsets, like “night +1 hour” because this is somewhat limiting:
I say limiting but it’s not exactly that. It’s not clear for me, I would rather say, how else to address this.
Don‘t think so. I think there is a way to dezermine if it is night time or daytine, which canbe used as „only if“ confition.
But I have to check….
No, not ephemeris, I will check later…
One can test the Elevation or Angle Channel for 0. It’ll be 0 from dusk to dawn. Link that to an Item and you can use the Item state condition to test it for 0.
One could also do a quick script to test using the Action Block library and a Scrip Condition.
In JS it’s be something like:
actions.get("astro", "id:of:astro:sun:thing").getElevation() == 0
No, that’s for day types (e.g. weekends) and holidays.
Now that we have the option to call Thing Actions for the Actions section of a rule, I wonder if it makes sense to be able to call those that return something as a condition, coupled with a test for the result. Then the Astro Action could be called directly and tested for 0 without resorting to a Script condition.
Ooh…. I think I’m following you…. Need some minutes in the app to see if I understood properly.
But see what I mean? Likely possible!
But completely non intuitive! >.<