openHAB 4.0 wishlist

My wish list is pretty simple. I want a better-looking thermostat widget for dual setpoint thermostats and a reboot schedule for openhabian in the web-giu. And please don’t tell me to just use crontab. I have never, ever, ever, got crontab to work for a reboot on any Linux install.

  • WebUi improvements:

    • oh-input:
      support ‘type: select’ and provide a solution to handle the entries so we are finally able to make use of nice filled comboboxes in the new ui.
      That way we can have a nice selector filled with one’s favorite selections wether it’s a simple radio channel selector or a complex mode selector without wasting space for a workaround by using buttons.
      It would be nice if there would be a way to map the entries for the oh-input in the oh-conf directory and it’s item files directly. In the past i’ve used the mappings= parameter in the sitemap, but since the new ui is here i’m rarely using the basicui anymore.
      → respective github issue #982 Can't add selection elements to oh-input type 'select' · Issue #982 · openhab/openhab-webui · GitHub

    • ohchart-series/echarts:
      make use of the respective locale / language and measurement System for all chart series.
      At the moment every user is being forced to use graphs in the English way of things.
      example see line 23: openhab-webui/oh-calendar-series.js at main · openhab/openhab-webui · GitHub ( no update since implementation )
      This code shows that a calendar chart ( also the other series ) will always show the values with 3 decimal places and use the English way of displaying the values.
      In europe we are using the #,### instead of a #.### as thousand separators in numeric values. This can really be confusing at times.
      It would be nice to remove this hardcoded way and make use of the respective openhab instance settings or use the active system locale for all series.
      for the values it would be nice if we could make use of openhab’s .displayState as a formatter for the values that are being shown in the graphs or even support
      echarts formatter function in some way.

  • A community developed ultra low power standby wifi audio-sink, that will be ready when oh 4.0 is =)

    • maybe use a cheap esp32 wroom for instance and some dac/amp combination as a base.
    • a relay/mosfet that completely cuts power from the amp while nothing is streamed and outputted on the speaker.
    • case will be 3d printable and also community designed.
    • optional: small display that will show whatever the user wants openhab to show. wether it’s temperature, notifications… preferably a small e-ink to keep power draw low or even a small oled or lcd.
    • optional: Adressable led stripe support for notification blinking or whatever.

    examples for inspiration https://squeezeesp32.blogspot.com/ https://raspiaudio.com/produit/esp-muse-luxe

  • A community developed 3d printable weather station esp32 based or similar.

    • maybe also esp32 based
    • optimized to be printable on most 3d printers
    • sensors: wind, water, lightning, temperature, humidity … to be discussed. maybe modular design.
    • option to be powerbank driven and solar rechargeable
1 Like

Mark, I think it already works good enough:

It actually searches over all text that it finds that is displayes which is why it also finds cOFFee when you search for OFF :wink:

The search bar doesn’t allow you to specify what parameter you want to search against but to me it works just fine.

Something that was really missing was

which I added and was merged before 3.4

1 Like

OpenHAB and openHABian are designed to run 24/7. That’s so much against design principles that it will not happen.

5 Likes

Thanks @stefan.hoehn, I didn’t know that. This will save a lot of time!

@vespaman Something like this: timeline picker?

@tose Well, sort of, but I meant this one

I quite often creates new “schedule rules”, and move existing ones around in time. If it was on a time line that could be dragged with the mouse it would be so much easier.
The timeline picker is (afaik) a more static solution where you have specific stuff that you want to move in time.

But when google assistant can’t reach openhab or something else goes wrong the first step is to reboot. Rebooting once a week (preferably at night) would keep things running smoothly and reduce troubleshooting. Even my NAS has an option to reboot on a schedule (mon morning at 3am). Notice I specified reboot not shutdown.

It’s an easy enough solution to setup openhab to reboot openhabian on any kind of schedule you’d prefer. Agreed this is a workaround to a root cause that should probably be investigated and fixed but there it is.

for example…

1 Like

No. You just need to open the cloud menu and press save. Nothing else.
Also, you should check the forums, there are beta bindings that the devs have been working on to address the issue.
How would you know that the issue is fixed if you’re randomly rebooting without interaction? Say that the issue is fixed on v3.4, you’d continue rebooting without a need for it.

Never reboot, it’s a bad practice from old times.

5 Likes

Let’s just keep this topic to wishes and if some wish can already be done in some way or another then provide the solution.

2 Likes

You should not be thinking you can create a binding through rules. If you need a binding, you need to cover a binding. If you are using Rules, skip the Things and populate the states of Items directly.

Library functions or even just using a banking pattern for items can be used to make this one done handle any number of locations.

Given openHABian isn’t magic and it pretty much only has cron available to use for this, I’m but sure you’d have any better luck that’s there.

Given Squeezebox can be used as an audio sink (I’m pretty sure), why reinvent the wheel here? Is there something it lacks?

I’m not arguing against any wish, just trying to narrow down what the wish means.

If at all possible, some sort of ‘native’ and official python3 support to make it easy to write own scripts without having to rely on helper/3rd party scripts that may or not be maintained and developed. Like an official python3 module that integrates with openhab.

(I know of habapp but its classbased and object oriented and seems uneccesary hard to understand how to use for atleast novice scripters/programmers like me. I use jython now and it works just fine so far but it’s old and outdated).

1 Like
  • Acts as a smart speaker, i.e. have a microphone and uses the keyword spotter, STT and openhab’s chat feature. This gets us completely free from google assistant / alexa.

I would really like to be able to write tests for my rules.

So I would imagine having a test environment, where I can mock items, things and triggers, invoke them and do assertions.

I find it rather difficult to write rules without being able to quickly write a test for them.

2 Likes

We can do this in jruby. This works on OpenHAB 3.3+
https://ccutrer.github.io/openhab-jrubyscripting/main/file.testing.html

1 Like

It does work for sure, that’s why i linked it. I do not want to reinvent the wheel, as i said for inspiration.
The main idea was to create let’s say a blueprint, bom, design, manual of a little device let’s say 20€ range that one can put together with it’s own hands that in the end does
output audio, voice, notifications, states and so on. @JimT already had the idea of also integrate a mic, sure i’m all in for these things.

:+1:

The goal is to have something that is “open” as in “openhab” not a closed amaphone home box like an alexa or similar. I’m sure there are many people that would love to have a plug and play device that does just that and works with minimal effort. I really like the mycroft mark 2 approach but that is already over the top and too expensive for a little speaker that one can have in every room. There are also a lot of people who don’t want to build themselves or can’t and i’m aware of that but that question can surely be thought of as we progress along and have the thing created =)

My vision behind the idea was that community input, development of the pysical thing itself as well as code development on the openhab side goes hand in hand together from the start.
It could be done in a thread where we have a timeframe for ideas, similar to this thread, poll the best → create.
Then another timeframe for pcb development, oh implementation, writing the manuals and so on.

But that’s already too much detail, let’s keep this thread a wishlist.
Feel free to rephrase my idea, i’m not that good in expressing myself. But i will surely answer a pm if there are more questions.

That being said have some happy days and keep wishlisting :wink:

PS. There are already a lot of great wishes in this thread. Let’s turn them into reality.

1 Like

Looks nice, but would love to have it in webui and for ecmascript :thinking:

Have you had a look at MyCroft https://mycroft.ai/ it has and OpenHAB skill by the looks of it Mycroft AI Skill | openHAB

+1 on more love for sitemap.

My system requires minimal interaction through the UI, so the old sitemap is good enough for me. Just one thing that would make it greater is to dynamically populate a list from an OpenHab items. This simple enhancement would make sitemap so much more powrful.

5 Likes