M3 testing results

I am happy with M3 so far as well.

Raspb Pi 3 B - openhabian

binding = amazondashbutton,amazonechocontrol,astro,denonmarantz,exec,fritzboxtr0641,gpstracker,harmonyhub,http1,km200,neato,netatmo,network,ntp,openweathermap,systeminfo,tankerkoenig,wol1,zwave

ui = paper,habmin,habpanel

persistence = jdbc-sqlite,mapdb

action = telegram

The only strange thing I see is, that the system binding reports now the CPU with
{channel="systeminfo:computer:Homer:cpu#load1"} (or 5 min …)

I get data, but PaperUI does not even show this channel.

It’s a known issue that when new channels get added to Things you need to recreate existing Things to use these.

That’s what I did.
But even the new thing does not show the channel load1 etc.
The only CPU related channel is
systeminfo:computer:Homer:cpu#name

You mean in the detail of a thing with the list of channels in PaperUI? It’s an advanced channel, and will be shown when clicking Show More. But I’m guessing you already tried that?

1 Like

As you can read in the upgrade / release notes, the load channel of CPU is not supported anymore due to changes in the used OSGi library.

This is about load1 not load (and OSHI)

Damn it - you’re right.
I knew that once, but that’s what’s happening, when you don’t use PaperUI for a long time :wink:
Thanks for pointing me into the right direction!

Ok my mistake. Thought it was the same.

I got a log entry I have never seen before:

Validation issues found in configuration model 'geofencing.rules', using it anyway:
Unreachable expression. 

How to find out where the issue is?
Usually the log shows the location within the rule to check [xxx,xx]

So what is
Unreachable expression?

EDIT:
Got it with SmartHome Designer (instead of VSC) - actually very obvious :wink:

rule "Geo Distance"
when
    Member of G_Locations changed
then
	var itemName = triggeringItem.name.toString
// skip distance calculation for TripStart and TripEnd Locations
	if(itemName == "CarTripFromLoc" || itemName == "CarTripToLoc") {
		return; // failing fast
		logInfo("geofencing.rules", "G_Location change - TripStart / TripEnd skipped")
	}

return; was misplaced :wink:

Unfortunately since a few versions openhab is getting more and more unstable for me: Startups are sometimes randomly failing (the Webinterface is loading forever and bindings aren’t loaded after a few hours), bindings stop to work or don’t load/startup properly (execute binding for example needs a bundle:restart at least once) and not even to mention the loading of rules without the underlying system being ready (which causes all kinds of weird errors, delaying the loading gets around it though). I haven’t seen anything suspicious in the logs though, so that’s making it hard to post issues on all of these.

Are you running openHAB on a raspberry pi with sd card?

No, I am running on an odroid c2 with the rootfs being on a NFS Server.

Are you sure there is not something network or permission related causing issues? NFS can be tricky at times.
I would shy away from having rootfs network mounted unless absolutely necessary as a temporary workaround until a permanent solution is deployed.

This is a way better solution than SD cards and is a lot more reliable. If there would be network issues there would be “NFS Server x.x.x.x not responding, still trying” in dmesg, but it isn’t. There is also no permission issue as I have openhab running as root as its a dedicated device just for openhab.

I might need to mention that my installation is quite big with more than 600 items, loading those also takes a while and I think that is a contributing factor to my rule issues (which is still no excuse that the fundamental underlying environment isn’t setup when rules are executed and it then never recovers from that situation).

I meant NFS mount permission issues since the filesystem is on a different server. I was a UNIX systems admin for years using NFS but not for a root filesystem.

I know, but this filesystem was setup from the client itself and that wouldn’t explain why it starts working after a bundle:restart and why the startup fails and after a service restart it succeeds. Also as root is mapped to root by NFS there shouldn’t be any issues. Also this started to appear with the recent builds, this setup was working fine for more than 3 years (if not more) before that, and on a different hardware another 4 years before (starting with openhab1 back then).

However, I’ll try to copy all my configs over and try to run it on a virtual machine, but giving it limited CPU power to come close to the real setup, just to rule this one out.

Here a RBP-4 with oh 2.5 m3 (openhabian)

Astro
Weather
Sysinfo
Xiaomi gateway
Ntp
Hue
Gpstracker
Mqtt
NEEO

System info doesn’t have all channels & memory channels doesn’t provide correct data.
Mqtt, doesn’t work with esphome device(ble to mqtt)

Let me know if need additional information

What is missing? The warning message on installation specifically states cpu load is no longer available.
I just installed M3 last night and a quick check looks good.
Which MQTT binding? Some people still prefer the v1 binding.

Morning,

In 2.5m3 systeminfo I can’t found:

CPU: Load (instant load) Load1, Load5 are ok

About the mqtt binding: mqtt embedded broker + mqtt binding the standard that include the version 2.5.m3

Thanks

CPU load is no longer in the binding according to the warning when installed. I gather that a change in an upstream library removed that.
MQTT v1 is also available in the current OH. I do not use MQTT though