openHAB 3.0 Release Candidates discussion

This topic can be used to discuss problems/experiences/questions on the openHAB 3.0 Release Candidates.


events.log doesn’t contain events after upgrade from M5 to RC1. This can be fixed by editing userdata/etc/log4j2.xml and changing all occurrences of smarthome.event to openhab.event.

1 Like

One of my rules failed to load:

Error during upgrade
I have tried to upgrade from M5 to RC1 using “sudo openhabian-config”, master and option 2 : Upgrade System - but I get the following error:

After running “sudo systemctl stop frontail.service” I can now upgrade to RC1.

  1. The startup wizard sets Country/Region in Regional settings but does not set the Country setting in Ephemeris (remains empty by default).

  2. NEATO binding: Account is online but scanning fails.

2020-12-14 21:22:23.557 [DEBUG] [internal.handler.NeatoAccountHandler] - Attempting to find robots tied to account
2020-12-14 21:22:25.630 [DEBUG] [internal.handler.NeatoAccountHandler] - Authentication Response: {“message”:“Not allowed”}

Manually adding the robot however works.

2020-12-14 21:34:34.289 [DEBUG] [.neato.internal.handler.NeatoHandler] - Will boot up Neato Vacuum Cleaner binding!
2020-12-14 21:34:34.290 [DEBUG] [.neato.internal.handler.NeatoHandler] - Neato Robot Config: NeatoRobotConfig [refresh=60, secret=REMOVED]
2020-12-14 21:34:34.290 [DEBUG] [ab.binding.neato.internal.NeatoRobot] - Will get STATE for Robot REMOVED
2020-12-14 21:34:34.290 [DEBUG] [.neato.internal.handler.NeatoHandler] - Start automatic refresh at 60 seconds
2020-12-14 21:34:34.291 [DEBUG] [ab.binding.neato.internal.NeatoRobot] - Calling Neato WS with body: {“reqId”:“1”,“cmd”:“getRobotState”,“params”:{}}
2020-12-14 21:34:35.473 [DEBUG] [ab.binding.neato.internal.NeatoRobot] - Result from getRobotState: {“version”:1,“reqId”:“1”,“result”:“ok”,“data”: {},“error”:null,“alert”:null,“state”:1,“action”:0,“cleaning”: {“category”:4,“mode”:1,“modifier”:1,“navigationMode”:2,“mapId”:"",“spotWidth”:0,“spotHeight”:0},“details”: {“isCharging”:false,“isDocked”:true,“isScheduleEnabled”:false,“dockHasBeenSeen”:false,“charge”:96},“availableCommands”: {“start”:true,“stop”:false,“pause”:false,“resume”:false,“goToBase”:false},“availableServices”: {“findMe”:“basic-1”,“generalInfo”:“basic-1”,“houseCleaning”:“basic-4”,“IECTest”:“advanced-1”,“logCopy”:“basic-1”,“manualCleaning”:“basic-1”,“maps”:“basic-2”,“preferences”:“basic-2”,“schedule”:“basic-2”,“softwareUpdate”:“basic-1”,“spotCleaning”:“basic-3”,“wifi”:“basic-1”},“meta”: {“modelName”:“BotVacD7Connected”,“firmware”:“4.5.3-189”}}
2020-12-14 21:34:35.477 [DEBUG] [ab.binding.neato.internal.NeatoRobot] - Successfully got and parsed new state for REMOVED

I’m having the same issue here…
using master of openHABian config tool and tried with option 40-41 | openHAB testing and 40-42 | Upgrade to openHAB 3

There is another process running as user openhab, @Erling screenshot shows it as 413.
Identify this process, stop it and upgrade again.

@Benjy What does the usermod do here? Is it really needed for updates ?

If your logs are full of warnings like these

Field 'firmwareStatus' could not be eliminated: Can not set final org.openhab.core.thing.firmware.dto.FirmwareStatusDTO field to null value

when you go to the settings in the UI, that’s my fault and a fix is on the way:

If you’re so annoyed and can’t wait to get rid of these messages, do a
(disclaimer: in theory you shouldn’t update untested bundles like this :stuck_out_tongue_closed_eyes:)


After migration from MR5 -> RC1 my rules triggered on Item-State-Changes did not fire. Manual execution of the rules worked fine.
After an additional reboot, the problem went away without doing other changes.

Thanks, in my case it’s PID 553:

openhab 553 0.8 1.2 144004 49088 ? Ssl 21:33 0:11 node /usr/bin/frontail --ui-highlight --ui-highlight-preset /usr/lib/node_modules/frontail/preset/openhab.json -t openhab -l 2000 -n 200 /var/log/openhab/openhab.log /var/log/openhab/events.log

when I kill this process it starts again with another PID and then I get the same message but with the new PID.
Upgrade errors out with the same message.

Don‘t kill the process, do a clean

sudo service frontail stop

or whatever command it takes on your system.
I normaly stop frontail before upgrading, as I also delete the logs.


ah perfect, thanks!
After stopping the frontail service the upgrade passed fine.
Weird as it’s the first time I needed to do this.

Hi All!
Tried to upgrade from M5 to RC1 in docker by replacing with new image. It got stuck in endless loop as it says “You are already on Openhab 3.0.0.M5” and restarts up upgrade process. If I put M5 image back it boots properly.

When the upgrade detects that the home directory is still /var/lib/openhab2 it changes it to the correct path. I hadn’t realised that openHABian still uses the openhab user for frontail (it shouldn’t do (cc @mstormi)). I’ll release a workaround.

1 Like

It’s probably the Portainer issue described in the README:

1 Like

Yes, when using portainer you have to delete the ‘OPENHAB_VERSION’-Environmentvariable of your OpenHAB-Instance before doing the upgrade.

1 Like

Right it shouldn’t and I’d think it doesn’t on fresh installs in quite a long time. If you have installed openHABian/frontail before this got fixed though you’ll still have the old user. Re-installing frontail via menu might help there.


6 posts were split to a new topic: Migration question

The ‘RC1-2’ might be the version with the fix, that @ysc mentioned above, already applied (but I’m not 100% sure)

In that case your commands would be:

sudo apt install ./openhab_3.0.0~RC1-2_all.deb

If you do a fresh install anyway, I would try it out and having a look in the logs after install - if anything looks good, you’re probably good to go. :slight_smile:

The ‘-2’ at the end is just for the .deb packaging, it fixes the following install error.

The content after the install is identical and is now given to anyone who uses the milestone/testing repository. Unfortunately that does mean the same issues are present.

1 Like