openHAB 4.3 Release Discussion

[ErikDB (Erik)]

On my Windows laptop at home (so going to http://192.168.1.9:8080/), the logging does come through. If I go through https://myopenhab.org/ on the same laptop (on the same home network), the logging fails. So that’s where the problem seems to lay. And I assume the Android app always uses https://myopenhab.org/…

A second problem, though. It shows all logs, which is too much Luckily, you should be able to filter. But the dropdown menu is broken…

Edit: I later understood the filter only works after you stop the “tail”. Which makes sense of course. But maybe it wouldn’t hurt to point that out for idiots like me

[TheNetStriker (David Masshardt)]

I just upgraded to OH 4.3.0 and tested the new Colortemperaturepicker.

Fist I found out that items have to be defined as Number:Temperature with {unit=“mired”} to get the color temperature picker to show up for my zigbee2mqtt lamps.

But for some reason the value sent via MQTT to zigbee2mqtt is always in kelvin instead of mired.

Am I doing something wrong here?

[rlkoshak (Rich Koshak)]

@Martin_HD

But now I only can copy and delete, I cannot see all the details, items or code and make any changes. I deleted browser cache & cookies already, also disabling / enabling the Thing is not helping. It is generic MQTT, not the HomeAssistant MQTT.

These are definitely managed Things, not defined in .things files? If so this might take some extended support so you might need to open a new thread. Post screen shots showing what you are seeing and, if possible, query for the Thing using the API Explorer and post the JSON defintion of the Thing.

[Lolodomo]

@TheNetStriker

Fist I found out that items have to be defined as Number:Temperature with {unit=“mired”} to get the color temperature picker to show up for my zigbee2mqtt lamps.

But for some reason the value sent via MQTT to zigbee2mqtt is always in kelvin instead of mired.

So use Kelvin (unit=“K”).
Both units are supported.

[TheNetStriker (David Masshardt)]

The values for my lamp are in mired, but Openhab sends them as kelvin. This then has no effect because the kelvin values are much to high.

Edit: I guess the problem could be that the Thing channel that was discovered by the Homeassistant binding is not recognizing that the channel value type should be in mired units. This is how the channel looks in the Api Explorer:

    {
      "linkedItems": [
        "DIMM_ZIGBEE_PC_1_Temp"
      ],
      "uid": "mqtt:homeassistant:4ce1d806:zigbee2mqtt_5F0x0017880100d20f2a:light#color-temp",
      "id": "light#color-temp",
      "channelTypeUID": "mqtt:ha-number",
      "itemType": "Number",
      "kind": "STATE",
      "label": "Color Temperature",
      "defaultTags": [],
      "properties": {},
      "configuration": {}
    },

[Lolodomo]

Yes, that’s true, the command from Basic UI is a value like “4000 K”. Normally any binding should be able to accept a value either in mirek or Kelvin. Maybe this is not handle properly by the Homeassistant binding.

[Lolodomo]

@TheNetStriker

: I guess the problem could be that the Thing channel that was discovered by the Homeassistant binding is not recognizing that the channel value type should be in mired units.

Apparently it is even not considering any unit, itt defines a simple Number while a number with temperature dimension is expected.
All bindings implementing a color temperature channel are now using a Number:Temperature.

[palazzja (JackP)]

Hi all.
Just migrated all my legacy Wiz items to the new Wiz 4.3 binding. All works.. but i don’t have a Light State On/Off function or brightness 0-100

[laursen (Jacob Laursen)]

@palazzja

i don’t have a Light State On/Off function or brightness 0-100

You can link such items to the color channel.

[palazzja (JackP)]

The Add On documentation specifically shows a brightness and power channel.
Using the color channel.. i cannot dim the white modes.

[florian-h05 (Florian H.)]

@ErikDB

A second problem, though. It shows all logs, which is too much Luckily, you should be able to filter. But the dropdown menu is broken…

Edit: I later understood the filter only works after you stop the “tail”. Which makes sense of course. But maybe it wouldn’t hurt to point that out for idiots like me

Can you please report this as issue on GitHub - openhab/openhab-webui: Web UIs of openHAB so we can have a look at it without forgetting it?

[florian-h05 (Florian H.)]

@supersjel

The type is changed from 4.2.x to 4.3 and OH doesn’t recognize it anymore. So probably the easy fix is changing the header.

Actually the server should still be able to run the script as the „old“ MIME type is still supported by the JS Scripting add-on, but the UI doesn’t recognize this and hence thinks the script cannot be
run.

@supersjel I have created a PR to fix that: Fix scripting add-on availability check for old JS Scripting MIME type by florian-h05 · Pull Request #2928 · openhab/openhab-webui · GitHub

[ErikDB (Erik)]

To be clear, once the ‘tail’ is stopped, the drop down menu does appear. Or do you mean it should also be there to filter the tail?

[florian-h05 (Florian H.)]

TBH I am not sure whether it should be configurable during the log tailing, or not.
Either way, the current state is not optimal so we should have a look and decide how to improve.

[ra_dzik]

Thank you very much for the new 4.3 version of OH. Update from 4.2.1 without any problems. Platform - Windows.
Gooood job! Thank you!

One question to the next planned version about Systeminfo Binding - when we can expect to update this binding with new OSHI version. As I see this binding has been developed in year 2016

[chris (Chris Jackson)]

@ErikDB

If I go through https://myopenhab.org/ on the same laptop (on the same home network), the logging fails.

As mentioned above, the logging is not working with openHAB cloud.

https://github.com/openhab/openhab-cloud/issues/478

[chris (Chris Jackson)]

@florian-h05

Can you please report this as issue on GitHub - openhab/openhab-webui: Web UIs of openHAB so we can have a look at it without forgetting it?

I suspect that this is being overloaded by heavy logging. I’ve seen similar, but not the same issue where if logging is coming in too fast for the logger to display, then the dropdown works, but it takes some time to catch up…

[wborn (Wouter Born)]

@ra_dzik

when we can expect to update this binding with new OSHI version

Just create a PR like [systeminfo] Bump OSHI to 6.5.0 by falkena · Pull Request #16821 · openhab/openhab-addons · GitHub to do it today.

[mas (Markus)]

@uk59821

As I understand in the openHABian part of the blog post it is “move to a Bullseye-based Linux distribution”.

Then why does the release notes v1.9.3 say:

• new Raspi OS basis as of October, 2024

→ This is Debian version: 12 (bookworm)

Is it a mistake in the OH 4.3 blog post?

[Martin_HD (Martin)]

@rlkoshak

@Martin_HD

But now I only can copy and delete, I cannot see all the details, items or code and make any changes. I deleted browser cache & cookies already, also disabling / enabling the Thing is not helping. It is generic MQTT, not the HomeAssistant MQTT.

These are definitely managed Things, not defined in .things files? If so this might take some extended support so you might need to open a new thread. Post screen shots showing what you are seeing and, if possible, query for the Thing using the API Explorer and post the JSON defintion of the Thing.

Today at work I used myopenhab.org → there I had the wrong behavior (Things can only be copied and deleted, nothing else, no items, no code). At home with direct 192.x.y.z access I can access all Things perfectly. So myopenhab.org seems to ‘swallow’ a few byte?