OH2 vs OH3, beginner's problems

Hi there.
I have following (but growing, I hope) setup:

  • several Sonoff 230V modules (Basic, Basic RF, 4CH Pro, Mini, Zigbee Mini, RF Bridge, Zigbee USB stick - CC2531),
    2 Orange Pi’s for hosting OH and companions:
  • OPi3 (4 cores at 1.8GHz, 2GB RAM, ARM) with OH2, and
  • OPi4 (6 cores at 1.8GHz, 4GB RAM, ARM) with OH3.
    Both with Armbian Buster with OH installed using system tools (apt, synaptic, NO compiling etc).
  • mosquitto MQTT broker on OH2 host → OPi3. Simple user / pass security, no SSL (yet).
    Connected with Eth and 802.11n WiFi.

Now the experience:

  • managed on both OH to make “things”, “channels” and “items” for Sonoff (and WeMos D1 mini) real world devices. CC2531 stick connected only to OPi4.
  • did not bother for now with “presentation level”, ie use Paper UI on OH2, and basic “overview” page on OH3.

Now the problem:

  • OH2 works relatively fast (giving user experience of “less than 3 secs response”) despite slower hardware. Items / things got updated in realtime if switched / changed by real world device / sensor. (use DS18B20’s, INA226, RF remotes). Gives reliable “look and feel”.
    But it lacks SECURITY by design!! So not to use in real world application! (imo), (do You want “anyone” switching off heating during Eastern Europe winter? -20*C outside :slight_smile: ).

  • OH3 it designed with (some?) security in mind, BUT gives UNRELIABLE “look and feel”:
    - readings, “items” (DS18B20, switches etc) stop to get updated quite short after OH3 startup (not all, ex I can get time reading from Tasmotized Sonoff but no switch state updated, if I change state from OH, it updates),
    - ZigBee got “on/off line” at random (from user point of view).
    - need to hit browser (Firefox, as my favourite SeaMonkey does not work with OH3, works with OH2!!!) “refresh” key on regular basis,
    - “big fat and heavy” look and feel.

Now how to:

  • pinpoint OH3 problems with responsivity (which config files shoud I attach?, what log info?),
  • change config.
  • what should I read about “how to make Your OH3 presentation layer appealing” :),
  • same question for security (granular), ie “Tom can only view AC temperature”, but “Alice can change them”.
    ?

As robustness is key for me, so I plan to use as much of intelligence on MQTT / Tasmota level as possible, using OH for “nice interface”.

Can you expand on this a bit? If you configure your system properly then no one but you should be able to adjust anything.

Have you opened a port directly to openHAB?

Just a comment:

I also noticed a pretty heavy increase in ressource use in oh3 compared to oh2. At least after switching to fully using the model, and UI rules.

I got problems opening several tabs at once and got java heap memory errors. It seemed to increase the more I used the rule editor and the model.

I upgraded my Synology NAS RAM from 2 to 16gb and everything is flawless now.
Have quite some rules and OH is sitting at around 2gb of RAM, but everything is smooth.

My old setup coming from oh2 was just using like 700mb.

Oh2 was running rockstable for years and so is oh3 with enough ram.

What do You mean “directly”?
I simply used WWW browser (mentioned) to open OH2/OH3 page(s).
And in OH2 I have no (even) concept of user and he’s rights on something!

If I remember correctly there is even a page on OH2 “security” with advice “NEVER expose OH page to public Internet”…

Ok, maybe OH3 is not like (Novell’s, who remember company?) NDS, but at least there is some concept of “user” and his “rights”.
Altrough it MUST be configured EXPLICITELY! By default “anyone” has already “user” (not “admin”) rights! This means (my ex), can switch Your(!!) AC off during -20*C period,
, but can’t “demolish” config. “Only”.

Sorry, I am OH beginner, so my look is from “outside”. But I have years of experience in systems like Novell, M$ “domains”, etc. Also uC programming skills. (But not in “objects”, JS, etc, jutst prefer “old” C, than C++).
My (20?) years experience with IoT’s is that their programmers don’t have even basic foundation in security.

Sorry, are You “crazy”?
16GB of RAM for “home command center”?
Is it not enough to render entire “Avatar” in RAM?
Am I missing something?

There SHOULD be RAM demand of KILObytes (ok, < 1MB!), for real time system logic.
OK, “presentation layer” (WWW, graphics, multimedia) MAY be RAM “hungry”, but let’s STOP to talk about GIGAbytes!

For those who may not remember: at 2000’s entire 11 floor building (active) Internet experience was satisfied by 2Mb (BIT!) symmetric link.

And even now there are nice devices like Atmel’s AVR with KILO bytes of different memories, making many useful things.
OK again, IPv4 Internet MAY need MB’s, even several to be comfortable. Look at ESP32!
But not GB!

Don’t get fooled!

Yes, but you say

Why/how do these people have access to your openHAB system?

We’re in 2022. Everything gets bigger. Feel free to create your own home automation as feature rich as openHAB with a tiny memory footprint.

For what it’s worth my openHAB instance sits at ~1GB RAM. But comparisons between systems should be taken with a pinch of salt as it really depends on your setup: what bindings, how many Items and Things, persistence services and more.

Anyway, you have 4GB to play with, and a fairly decent processor, so something else must be wrong. Do the openHAB logs give any clues?

“Why/how do these people have access to your openHAB system?”

  • just for fun? We are 2022… IF You(!!) want some “remote access” (ex from phone, just for convenience), so You MUST expose something to Inernet. (IP + port).
    That’s appealing for many people. Point.

“We’re in 2022. Everything gets bigger…”

  • OK, let’s transfer this paradigm into money dimension: 50$ “central device” should be “acceptable”, 100$ (*price of first Sinclair’s ZX Spectrum!!) should be “light speed”. (for me, OPi3 / OPi4).

Do You agree?

“Anyway, you have 4GB to play with,…”
Ooops, I (personally) have 8GB, Fedora (35, on i7 Core) doesn’t exhaust this. To be true I didn’t noticed “light speed” as of migrating from 4GB to 8GB. Change to SSD did that change of experience.

REASONNABLE demand for resources is OK. “I need to display 1MB - 1024x768 picture, give me 2MB of mem”. But the same, with say 12MB (what for? really need 4096x2048 image? Do You (as human) perceive difference?)) and demand for 100MB? Crazy for me.

Look at AVRs, even ARM.

BTW, don’t feel offenced, it’s just a (ideas / experience) discussion :slight_smile:

BTW2 , I just use 1Gb(E) for “remote” (LAN) session of X11 @ 1920x1024. Don’tttttt see difference to local (HDMI) display, even with movies. But do “we” really need this level of troughtput on WAN?

Not everyone has access to fiber!
And (x)DSL is limited to say 20Mbps…

Back to my first point then:

If you have opened a port directly to openHAB then you’re going against the standard published advice. Get a reverse proxy in-between the two and configure it properly so only you have access. This has been the recommendation since at least OH2, if not before.

No, because in addition to changing hardware you have also changed the software.

All other comments are irrelevant. OH3 is what it is. If you want help you will have to provide configurations and logs. When you’re ready grab those and share them in between code fences.

“If you have opened a port directly to openHAB then you’re going against the standard published advice. Get a reverse proxy in-between the two and configure it properly so only you have access. This has been the recommendation since at least OH2, if not before…”

“All other comments are irrelevant. OH3 is what it is. If you want help you will have to provide configurations and logs. When you’re ready grab those and share them in between code fences.”

Ok, which log file and how filtered (grep)?

BTW OH Android app looks as it uses web APi to do work.
Not dangerous?
Works for OH2 but for OH3 says about relaxing security.

Let’s return to my problems :slight_smile:

Please get the basics.

  1. No open ports to the internet.
    Either use myopenhab to get remote access or use vpn. Wireguard is pretty simple to get up and running (please, separate computer, best practice would be wireguard in the router)
    If you want to expose openHAB directly to the internet, use a reverse proxy to get (at least) some security.
    This is valid for every version of openHAB, not just OH2.
    Please be aware that login is not meant for security in the meaning of “no hacker is able to get into, haha!” but only in the meaning of “Noone will destroy configuration by accident!”

  2. openHAB is 100% Java. That is: you will need a certain amount of memory even without openHAB running at all, only to get the platform up and running.
    Yes, would be nice to get a really small footprint for the system, but on the other hand, well… as mentioned before… it’s 2022…
    And in question of a ESP32: You won’t get a cheese cake from some peanuts. If you want peanuts, eat peanuts, if you want cheese cake, don’t complain about peanuts smaller than cheese cake…

  3. I’m not familiar with Orange Pi, but it’s best practice to use a decent OS (this is a debian bullseye without(!) desktop) and openHABian (see openHABian | openHAB to install openHABian on top of any debian-like Distro)

  4. Did you check wether the Orange Pi 4 is ok? This is: is it stable for some Days when running another Image of openHAB2, of other Software like Plex or something similar?

  5. Please don’t use the graphic interface of the Server. Instead, use a Browser on your local network and ssh to get command line access.

You’ve listed several independent problems with not enough details. Pick one and elaborate (e.g. pick one binding that stops updating Items). Logs from the relevant binding and perhaps events.log will be revealing. At a minimum, it will tell us whether the problem lies in the binding/device or in the UI. Seeing the Thing, Item, and UI widget configs can be revealing too.

I’m not convinced that your OH 2 system was particularly healthy because I know of no home automation technology where it takes three seconds to process a command.So what ever is causing that delay may be exacerbated in OH 3 somehow.

Depends on what you want to change.

First of all, you still have BasicUI and HABPanel if you don’t like MainUI. Beyond that learning how to work with MainUI the Getting Started Tutorial’s Pages sections and the User Interface Guide sections that talk about pages and the component reference will be your primary resources.

If you haven’t already, I recommend reviewing the entirety of the Getting Started Tutorial.

OH 3 has role based security with two supported roles: admin and user. And the only security provided here is that users cannot access the admin sections of MainUI, Things, rules, etc.

There is a visibility property on widgets that can let you hide widgets or even whole pages from user or admin, but it’s just hiding the UI element. It does not block access from a knowledgable user to access the API to manipulate those Items.

There was a bug in the rules engine that has been fixed as of the most recent milestone release.

Assuming that was the source of your problem that at least should be fixed now and OH 3 should not require as much RAM and shouldn’t have OOM exceptions any longer (at least until a new memory leak is introduced somewhere).

OH does not and has never claimed to provide real time system logic. If that’s what you are looking for then you are likely going to be disappointed with openHAB.

There are many ways to access openHAB remotely, some of which require exposing a port to the internet and many that do not. The recommendation for most users is to use myopenhab.org which does not require exposing your LAN to the Internet. Your openHAB instance initiates a connection to myopenhab.org and myopenhab.org acts as a reverse proxy of sorts for authorized users.

I won’t address the security discussion except to say.

  • From the beginning OH has largely relied on securing your LAN for it’s primary protections. So if you don’t want your ex to access OH, don’t give them access to your LAN. If you do have untrustworthy users on your LAN, you can limit access to only certain devices through firewall rules, implement some sort of zero trust architecture (there was a recent discussion on Cloudflare’s offering on this forum) or maybe OH is not a good fit for you. This is the current state of OH security.

  • Many have complained and demanded radical changes to how OH implements security. Few have volunteered their time to submit anything close to a PR that implements it. Continuing to hash this topic out over and over here on the forum accomplishes nothing except making people angry.

  • "God thanks for You, Udo, "liight_smile:

“You’ve listed several independent problems with not enough details. Pick one and elaborate (e.g. pick one binding that stops updating Items).”

OK, lets concentrate. as You wish: "
.

  • “user experience” far below 3 secs sorr MEn,

OK, which binding(s)? Do they depend on a mesh network (e.g. Zwave or Zigbee)? If so do you have a lot of mains powered devices in the mesh network?

Show your Thing(s) config.

Show your Items.

Show some relevant logs. An important detail will be whether the delay is before the command event appears in events.log or whether it appears after.

What is the CPU/RAM/System Load on the machine when you see this delay?

Are rules involved? If so show them. Explain what they do.

You have years of experience in IT. It shouldn’t be too hard for you to proactively guess what sort of information might be relevant instead of having us pry it out of you by playing 20 questions.

Suffice to say that a three second delay is not typical and not a problem that has been often reported. When it has been reported, the problem often lies outside of OH itself (not enough RAM, slow network, poor mesh for Zwave/Zigbee, etc.). But with the information presented thus far :person_shrugging: Could be anything.

Ok Rich, let’s start from beginning:

  • MQTT binding, “Tasmotized” Sonoffs (Basic, Basic RF, 4CH Pro).

  • DS18B20 attached to sonoffs, one INA226 to WemosD1 mini (Tasmota).

  • TWO installs of OH, one OH2, one OH3.

  • OH2 on OrangePi3 (2GB RAM), along with Mosquitto.

  • OH3 on OrangePi4 (4GB RAM),
    Same bindings, things, items (except OH3 has an CC2531 usb dongle for ZigBee, but don’t talk about this now).

  • OH2 - “user experience” - “realtime” - to explain: I switch an Sonoff 4CH Pro relay port using 433MHz button, → I can see WWW page of OH2 change in less than 1s. That’s “realtime” for me. Human realtime, not let’s say PLC realtime :).
    Thermometer readings (also voltage from INA and Sonoffs POW) updated - their update period is set to 60s,
    And reverse, I switch “Item” on WWW, “the light is on”, “now”.
    RELIABLE

NO rules, “scenes” “no UI” (for now).

But has not even concept of security.

  • OH3 - unreliable, sometimes (rather frequently) need to “reload page”, MQTT items stop (but not all) to update afer some time (after OH restart).
  • ex: I don’t get temperatures updated (all from DS18B20 on some ESP8266 device, Tasmotized), but I DO get update of time from one of Sonoffs!.

Pls tell (exactly) which files from /usr/lib/openhab/ (Linux, Armbian Buster) You want. Will zip them and attach (unless they contain some security info). As I can see a lot of file there.

I have tried to clean OH3 config, removing all unnesessary bindings / things.

Is it possible to “copy-paste” config of ZigBee from OH3 to OH2?? (same controller), I would like to try how ZB behaves on OH2.

OK, so let’s look at MQTT.

In general MQTT is very fast and reliable. It’s one of the most used technologies on openHAB. So there is something unusual going on.

There is a whole bunch of stuff between a device and the UI: device to MQTT Broker, MQTT Broker to OH binding, OH binding to OH Event Bus, OH Event Bus to UI. Each of these needs to be looked at in turn.

  1. Look at the messages coming from the device using an MQTT client, like MQTT Explorer. Eliminate the edge devices as the source of the delay. It’s probably not but if our assumptions were right everything would be working right.

  2. Look at events.log. Do you see the Items changing when new messages arrive (as confirmed through MQTT Explorer)? If not the problem is most likely in the binding/Thing config or something. If so …

  3. If you see events on the Items in events.log but the UI is not updating, the problem is between the UI and the server. What part of the UI are you looking at to see the Items updating?

As for the not getting temperatures updated at all, that’s most likely a misconfiguration on the Thing somewhere. Maybe it’s subscribed to the wrong topic. Maybe the topic was entered as a command topic instead of the state topic. Without knowing the specific topic and message the device is publishing coupled with the actual Thing configuration :person_shrugging: .

There are two unrelated problems here (neither of which has to do with a three second latency).

Items stop updating

I don’t really need anything because I can’t do this for you. You’ll need to watch your live running system and correlate what you are seeing in MQTT Explorer with what you are seeing in events.log with what you are seeing in the UI.

Once you can pinpoint where in the path the messages get lost (or are never sent in the first place) we will know where to look next.

No Thermometer Readings at all

What I’d need to double check your config:

  1. The topic that the device publishes to
  2. An example message published to that topic
  3. The Thing config. If using .things files just copy that. If using the UI, click on the “Code” tab at the top and copy and paste the YAML you see there
  4. If in a text file, the Item’s config. If not, list the Item type, any metadata you’ve added to it, confirm that there is a link between the Item and the Thing’s Channel.
  5. Where in the UI are you looking for the updates? If there’s a custom widget involved, click the code tab and paste that YAML too.
  6. Anything relevant in the logs around the time that a message should have been received and processed.

When pasting logs, YAML, or other configs, use code fences.

```
code goes here
```

In general no, configs are not usually backwards compatible, particularly with Things. However, you should only need to manually add a Zigee coordinator Thing and then discover all the rest of the Ziogbee devices in the inbox. That part works the same in both OH 2 and OH 3.

" In general MQTT is very fast and reliable. It’s one of the most used technologies on openHAB. So there is something unusual going on"

1). RIGHT, I have some MQTT → PostgreSQL logging, then parsing JSON in SQL, then GD::Graph in Perl to graphs.
Works.
Also works OH2 connected to same “things”, same MQTT broker.
I may export from Postgres, along with OH logs, if You want.

2). will look at events.log (if I find this…)

I am getting T reads, even Voltage, but this stops updating after some time.

Ok for “3 `” it’s familiar to me :slight_smile:

For ZigBee, OK, I’ll go trough entire path → coordinator → discovery → link.

Nice reading for tomorrow :slight_smile: THX :slight_smile:

I read manuals as last ressort, sorry, “old school”.

Good luck in your endeavours.

Maybe I have found too many badly written manuals. Last years.
But I have read also many fascinating books, like “Death march” by E. Yourdon :slight_smile: