Interoperability with other OpenHAB instance

atd · March 17, 2020, 8:30pm

I am trying to bring another existing OpenHAB instance in the mix, and I figured out that the easiest way to use the MQTT binding to connect HestiaPi’s MQTT server.

Everything is great, I just replicated TemperatureSetpoint, Temperature, even HeatingState.

However, I cannot fully integrate HeatingMode. The problem is that its state doesn’t get updated. If I change it the UI, it doesn’t get updated in the second OH, and the other way around.

HestiaPi’s OH thing is defined:

  Thing mqtt:topic:mosquitto:HeatingMode {
    Channels:
      Type string : string "HeatingMode" [
        commandTopic="hestia/local/cmnd/heatingmode",
        stateTopic="hestia/local/stat/heatingmode",
        retained=true
      ]
  }

and I see in the one-ui code that the UI suscribes to hestia/local/cmnd/heatingmode and publishes to hestia/local/stat/heatingmode

So I created the HeatingMode thing in the second OH the other way around, with commandTopic="hestia/local/stat/heatingmode" and stateTopic="hestia/local/cmnd/heatingmode"

But the HestiaPi OH HeatingMode thing does not update hestia/local/cmnd/heatingmode when its state changes

I have tried to add postCommand=true to HestiaPi OH HeatingMode thing without success.

Should I take a different approach?

rlkoshak · March 18, 2020, 6:54pm

I’ve so thoroughly rewritten my configs I might lead you astray so take this with some caution. I don’t think I changed that aspect of the configs though.

On my main OH I have a Thing that uses the cmnd topic for both the commandTopic and the stateTopic. There are a couple of extra messages received (publish to the cmnd topic from the main OH which then arrives as a new message on the stateTopic) but it then stops because the Item stays the same state and I don’t have any Rules that do anything with received command on that Item.

Let me know if that works. If not I’ll dig into it deeper.

For reference, here is my main OH instance’s Channel config for HeatingMode

Which would be roughly equivalent to

Type: string: string "HeatingMode" [ commandTopic="hestia/local/cmnd/heatingmode", stateTopic="hestia/local/cmnd/heatingmode", retained=true]

I spend sooooo much time working with people who don’t get the Thing syntax right for MQTT that I don’t use .things files anymore. Based on my experiments, not doing so shaves almost half a minute off of the boot time for the HestiaPi.

atd · March 19, 2020, 8:25pm

Sorry but it doesn’t seem to work

The UI in HestiaPi now changes with the main OH, but HestiaPi’s OH does not follow them

UI commands HestiaPi’s OH using the stat channel, but using the cmnd does not work

So storing configuration in JsonDB is faster than text files?

I am using JsonDB because I’d say I read in the documentation it was better to use the UI for things but text files for items, rules and sitemap.

rlkoshak · March 19, 2020, 10:30pm

I’m not in a place where I can test it out but I’ll try to see what works when I get a chance. But I have changed the mode using that Thing before and it worked at some point or at least appeared to. But I pretty much never try to do stuff from the LCD so I can’t say whether or not it works when commanding the mode from the LCD like that. But it should.

When you change the mode using the LCD it publishes to the stat topic. The stat topic is subscribed to as a stateTopic on the Hestia OH so that will cause the binding to postUpdate the HeatingMode Item to the new state. The HeatingMode Rule triggers on change instead of command so it will trigger the Rule on the HestiaPi OH no problem.

The HeatingMode Thing on your main OH though would not have received the message because it’s subscribing to the cmnd topic for the stateTopic. So this is probably where it’s breaking down. You need to subscribe to the stat topic in order for your main OH instance to see the updates published from the LCD.

Now, let’s consider the other direction and you want to send the command to the Hestia from your main OH instance. You sendCommand to the HeatingMode Item on your main OH instance which then goes to the binding. The binding publishes the command to the stat topic (topic linked to commandTopic). Your HestiaPi OH will see that message since it subscribes to the stat topic and it’s HeatingMode Item will change state which will trigger the Rule and the heating will turn on. So far so good.

But the LCD won’t change because the LCD doesn’t subscribe to the stat topic, it subscribes to the cmnd topic.

I’ve not looked at this thoroughly yet but I think the following will work. On your main OH instance, configure your Thing exactly the same as the HestaiPi’s Thing: commandTopic to the cmnd and statetopic to stat. Then we will assume that the One UI will publish the result of it processing the command to the stat topic for us. So the flow will be:

Main OH publishes to cmnd topic
One UI processes message, changes its state and publishes the change in state to the stat topic
HestiaPi OH receives the message from the stat topic, changes the state of HeatingMode which kicks off the Rules to activate the new mode.

One thing to remember is HestiaPi has OH deployed to a RPi 0 which is far below the minimum recommended specifications for running OH. That’s why it takes 20-30 minutes for the HestiaPi to book and become usable. Parsing and converting the text configurations is processor intensive and the RPi 0 only has one very low powered core. So it takes a good deal of time to parse the text configs and almost half of that 25-30 minutes is loading and parsing the .rules file alone. It takes a lot less work for the JSONDB files because it is almost just a matter of mapping the files into memory and it’s done, no parsing and very little syntax checking required.

Given this extreme amount of time required to boot, it’s worth the loss of some of the convenience (for developers) and features (that HestiaPi isn’t using anyway) that cause the recommendation for using text configs for everything but Things for general OH not the best choice for HestiaPi. So I’ve been working to move everything (including Rules) to JSONDB and so far I’m seeing very good results. The time from the blank white screen on the LCD to a working HestiaPi is almost exactly 10 minutes for me right now. It could be faster but there is no working System started Rule trigger for JSONDB Rules right now that I can use to trigger the initialization Rule to run. If I had that I could shave another minute or two off the boot I think as we don’t have to wait around for the load to drop before allowing the rule to be loaded and run the initialization.

Another advantage JSONDB everything has for users is you can see and change just about anything you would want to through PaperUI. Imagine being able to change the rule that determines when to turn on/off the heater to use a hysteresis in the calculation without needing to edit the files, and it takes effect immediately without a 10 minute wait while OH parses and loads the new .rules file. That’s what I’m trying to achieve. And I’m very close. There are a couple of small quirks with how the LCD is behaving I want to iron out and I want to add a check to not allow Cooling Boost mode to turn on when it’s already Heating and visa versa.

Some things though can only be done in text configs, including sitemaps. The Items linked to the GPIO binding also must be in .items files.

Anyone who wants to alpha test what I’ve done let me know and I’ll see if I can get it to you. It will require a bit of work to install though because you will need to stop OH, remove some files and copy some more file to another folder.

atd · March 21, 2020, 8:50pm

This is not happening right now. One UI just updates the interface but it does not forward the state change back to the stat topic

I don’t have much time, but I can try

I am integrating ANAVI Thermometer, so I need to touch the configuration. I also want to clean it up, so if your JSONDB rewrite is faster, I can use it as start point

I didn’t expect that text files introduced that much overhead

rlkoshak · March 23, 2020, 9:18pm

I’m still tracing down a bug on reboots where the screen doesn’t reflect the state I want it to (i.e. if the Fan happened to be ON before restarting but Heating or Cooling are also ON, I want the LCD to default to Heating or Cooling, not Fan when it comes up. Beyond that it seems to be working fairly well.

How familiar are you with how OH works and the JSONDB configs? If I drop a zipped up backup into Google Drive would you know what to do with it, or do I need to write up some docs? There are changes to pretty much everything, sitemap, items, rules, etc. And I depend on some new features in OH 2.5.3 so you will need to upgrade your OH as well.

If you don’t have a lot of time I completely understand if this is too much to look at right now. But if you are planning on cleaning up the configs anyway, this might actually save you some time in the long run.

OK, in that case in order to have the UI update and the Rule triggered, you need to publish to both topics from your main OH. To do that you need one Channel with the stat Channel configured for the commandTopic and another Channel with the cmd topic configured for the commandTopic. Have one of them subscribed to the stat topic as well. Then link both Channels to the same Item but link the Channel that is not subscribed to the stat topic second and set up a follow profile. This will forward any command you send to both Channels and therefore to both topics. That should update the LCD and trigger the Rule.

Let me know if you need help with any of that.

atd · March 27, 2020, 9:02pm

I know how to place the files under /etc/openhab2. I am not so sure about the ones at /var/lib/openhab2/jsondb. I located the things at org.eclipse.smarthome.core.thing.Thing.json but I am not sure if I need to do anything more than dropping the files and restarting the service.

Sure, I am willing to help and try it. It is only about settings expectations. As an example, I was able to reply to your message after 4 days

Is this still the case with the new configs? If not, I will wait

rlkoshak · March 30, 2020, 2:29pm

It works pretty much the same as the /etc/openhab2 files but you want to stop openHAB first.

I submitted a PR with all the changes to github here.

You will notice there are three root directories.

home/pi/scripts : Needs to be copied to /home/pi/scripts
etc/openhab2 : Needs to be copied to /etc/openhab2
var/lib/openhab2 : Needs to be copied to /var/lib/openhab2

To upgrade you would follow the following steps:

sudo apt update
sudo apt upgrade, accept all the upgrades and make sure that openHAB is in the list of upgrades and it is upgrading to 2.5.3-1. This might take awhile.
Stop openhab.
Run /home/pi/scripts/backup.sh and move the backup.zip file somewhere safe.
git clone https://github.com/rkoshak/hestia-touch-openhab.git to pull down the new configs.
mv /home/pi/scripts /home/pi/scripts.old. Then cp hestia-touch-openhab/home/pi/scripts /home/pi/scripts.
sudo mv /etc/openhab2 /etc/openhab2.old. Then sudo cp hestia-touch-openhab/etc/openhab2 /etc/openhab2. Finally sudo chown -R openhab:openhab /etc/openhab2.
sudo mv /var/lib/openhab2 /var/lib/openhab2.old. then sudo cp hestia-touch-openhab/var/lib/openhab2 /var/lib/openhab2. Finally sudo chown -R openhab:openhab /var/lib/openhab2.
sudo reboot

I like to log in via ssh right after the LCD goes to the “loading” screen and run tail -f /var/log/openhab2/openhab.log in one terminal and run top in another one. Even better would be to install multitail and htop and run those instead but tail and top are perfectly suitable. Watch for errors and over all load progress in the tail and pay attention to the load average in top. You will see “System is ready to operate, kicking off restored behaviors” when everything is done loading and initializing which should be only about ten minutes now as opposed to the 25-30 minutes.

You can see and modify all the Rules in PaperUI now and you can see them running.

See the PR link above for a brief tour of the Rules and how they interact with one another. I recommend that if you want to customize a Rule that you disable it first (press the alarm clock icon) and then create a new version. That way you are a couple of clicks away from restoring back to the known working Rule if you run out of time or run into trouble.

Each individual Rule is made up of three clauses (as opposed to the two for Rules DSL).

When… : the same as the Rule triggers when clause in Rules DSL
then…: the same as the Rule body in Rules DSL, where the code goes
but only if…: a set of conditions that are checked before allowing the Rule to run, for example, don’t let the HotWater Control Rule to run unless the SystemType == “EU”.

The script code is written in JavaScript but except for a few minor details it will look a whole lot like Rules DSL code.

There are a few convenience functions defined in /etc/openhab2/automation/lib/hestia/utils.js that get imported to some of the scripts that need to do things like logging or accessing createTimer and such.

I have not changed the OneUI at all and have no plans to (I don’t know how it works at this time) so this is still the case, you need to publish to both topics.

atd · March 30, 2020, 8:09pm

I quickly reviewed the PR and added some comments. I would like to take a deeper look to JSONDB files and perform a diff with my current setup (for example, I am using Javascript transformations for integrating an open thermometer that would be lost).

I find instructions pretty clear. I would try it as soon as I get some time. I am eager to try them! I will learn a lot BTW. Thank you for your work!

HestiaPi · March 30, 2020, 11:45pm

Just tried your steps to pull the PR code…
A few minors changes to your commands:

sudo apt update
sudo apt upgrade
sudo openhab-cli stop
git clone --single-branch --branch jsondb  https://github.com/rkoshak/hestia-touch-openhab.git
mv /home/pi/scripts /home/pi/scripts.old
cp -r hestia-touch-openhab/home/pi/scripts /home/pi/scripts
sudo mv /etc/openhab2 /etc/openhab2.old
sudo cp -r hestia-touch-openhab/etc/openhab2 /etc/openhab2
sudo chown -R openhab:openhab /etc/openhab2
sudo mv /var/lib/openhab2 /var/lib/openhab2.old
sudo cp -r hestia-touch-openhab/var/lib/openhab2 /var/lib/openhab2
sudo chown -R openhab:openhab /var/lib/openhab2
sudo reboot

Followed by

sudo openhab-cli stop
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo reboot

Leaves me in a strange state with warnings like this

2020-03-30 23:37:58.636 [WARN ] [me.core.service.AbstractWatchService] - Directory 'things' does not exist in '/etc/openhab2'. Please check your configuration settings!
2020-03-30 23:37:58.640 [WARN ] [me.core.service.AbstractWatchService] - Directory 'rules' does not exist in '/etc/openhab2'. Please check your configuration settings!

and lots of errors like these:

[ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14

I’m not 100% sure the image I started off was in perfect state so unless you see anything obvious, I will try again from scratch and come back with useful info.

rlkoshak · March 31, 2020, 2:04pm

Hmmmm. Are both of those folders indeed missing from /etc/openhab2?

I do see that I’ve not checked in those folders to etc/openhab2 and I must have forgotten to add the steps to recreate them when I wrote the above steps.

After the sudo cp -r hestia-touch-openhab/etc/openhab2 /etc/openhab2 add the following two commands.

sudo mkdir /etc/openhab2/things
sudo mkdir /etc/openhab2/rules

That will make sure those folders exist. I didn’t check in these empty folders because they are empty and when someone is upgrading they will already have an OH installation. I can check in both empty folders to make this process easier.

The clean-cache is probably unnecessary. It was performed by apt when you did the upgrade. I’d only recommend doing it again if you actually experience a problem where a reinstall of the bindings is likely to fix it.

I’m aware of those and for now they can be ignored unless they persist showing up after you see the “System is ready for operation” log statement. I need to go in and prevent a couple of Rules from running unless the Setpoint and PreviousXReading Item have a usable value. The error just means that one of two Rules is running before PreviousXReading (probably PreviousTempReading) has a usable state. Once the Initialization Rule has a chance to run for the first time it should get initialized to 0 and restoreOnStartup should prevent the error from that point onward.

But I’ve also seen similar errors on MyTempProxy so there are definitely some more error checking on some Rules to prevent them from running until everything they need have a valid value. For now, you can ignore those types of errors until after initialization completes. If they persist after initialization completes let me know.

Initialization gets kicked off when default.rules is copied from the scripts folder to the rules folder by the kiosk-xinit.sh script. default.rules now contains a single Rule that sendCommand to StartInitialization which causes the Initialization Rule in the JSONDB to run.

So the full set of commands to run would be:

sudo apt update
sudo apt upgrade
sudo openhab-cli stop
git clone --single-branch --branch jsondb  https://github.com/rkoshak/hestia-touch-openhab.git
mv /home/pi/scripts /home/pi/scripts.old
cp -r hestia-touch-openhab/home/pi/scripts /home/pi/scripts
sudo mv /etc/openhab2 /etc/openhab2.old
sudo cp -r hestia-touch-openhab/etc/openhab2 /etc/openhab2
sudo mkdir /etc/openhab2/things
sudo mkdir /etc/openhab2/rules
sudo chown -R openhab:openhab /etc/openhab2
sudo mv /var/lib/openhab2 /var/lib/openhab2.old
sudo cp -r hestia-touch-openhab/var/lib/openhab2 /var/lib/openhab2
sudo chown -R openhab:openhab /var/lib/openhab2
sudo reboot

I’m not certain the clean-cache and reset-ownership is necessary after the first reboot. The chown commands have already set the ownership. The apt upgrade already cleared the cache.

Let me know if you see any other problems or have other questions. I was only able to test this transition once and in the great debate I fall on the side that programmers are incapable of properly and fully testing their own code. They know how it is supposed to work and have blind spots to potential miss uses that can cause errors. So your feedback is very very appreciated.

HestiaPi · March 31, 2020, 10:27pm

Tried the mkdirs and the rest of the steps and now it boots and waits. Once I visit the BasicUI at below timestamp 2020-04-01 01:19:49.860 I get these errors:

==> /var/log/openhab2/openhab.log <==
2020-04-01 00:59:54.148 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.items'
2020-04-01 00:59:54.810 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mapdb.persist'
2020-04-01 00:59:56.034 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.sitemap'
2020-04-01 01:00:00.194 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2020-04-01 01:00:04.648 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://10.10.10.51:8080
2020-04-01 01:00:04.651 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://10.10.10.51:8443
2020-04-01 01:00:05.424 [INFO ] [b.core.service.AbstractActiveService] - HTTP Refresh Service has been started
2020-04-01 01:00:09.295 [INFO ] [openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2020-04-01 01:00:22.168 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.rules'
2020-04-01 01:00:23.581 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'default.rules'
2020-04-01 01:19:49.860 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item SystemType for widget org.eclipse.smarthome.model.sitemap.sitemap.F                                                                                                                                                 rame
2020-04-01 01:19:49.865 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.870 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.873 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item TempUnit for widget org.eclipse.smarthome.model.sitemap.sitemap.Set                                                                                                                                                 point
2020-04-01 01:19:49.876 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.880 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.884 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.887 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.889 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.892 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.895 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item TempUnit for widget org.eclipse.smarthome.model.sitemap.sitemap.Set                                                                                                                                                 point
2020-04-01 01:19:49.897 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.900 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.903 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.905 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'TempSetpointF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoin                                                                                                                                                 t
2020-04-01 01:19:49.908 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.911 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item TempUnit for widget org.eclipse.smarthome.model.sitemap.sitemap.Tex                                                                                                                                                 t
2020-04-01 01:19:49.913 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.916 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.918 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyC' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.921 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.923 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item TempUnit for widget org.eclipse.smarthome.model.sitemap.sitemap.Tex                                                                                                                                                 t
2020-04-01 01:19:49.925 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.927 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.929 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'MyTempProxyF' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:49.932 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item SystemType for widget org.eclipse.smarthome.model.sitemap.sitemap.F                                                                                                                                                 rame
2020-04-01 01:19:49.934 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'HeatingMode'
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'HeatingMode' could not be found in the item registry
        at org.eclipse.smarthome.core.internal.items.ItemRegistryImpl.getItem(ItemRegistryImpl.java:85) ~[?:?]
        at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getItem(ItemUIRegistryImpl.java:837) ~[?:?]
        at org.openhab.ui.basic.internal.render.SwitchRenderer.renderWidget(SwitchRenderer.java:85) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:194) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:160) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:181) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:124) [bundleFile:?]
        at org.openhab.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:189) [bundleFile:?]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [bundleFile:3.1.0]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
2020-04-01 01:19:49.967 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:49.970 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:49.972 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:49.975 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:49.977 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:49.980 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:49.982 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.984 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item HeatingRemBoostTime for widget org.eclipse.smarthome.model.sitemap.                                                                                                                                                 sitemap.Setpoint
2020-04-01 01:19:49.986 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:49.989 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.991 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:49.993 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:49.995 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:49.997 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:49.999 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item HeatingRemBoostTime for widget org.eclipse.smarthome.model.sitemap.                                                                                                                                                 sitemap.Setpoint
2020-04-01 01:19:50.001 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.003 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:50.005 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.008 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'HeatingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.011 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item SystemType for widget org.eclipse.smarthome.model.sitemap.sitemap.F                                                                                                                                                 rame
2020-04-01 01:19:50.013 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'CoolingMode'
org.eclipse.smarthome.core.items.ItemNotFoundException: Item 'CoolingMode' could not be found in the item registry
        at org.eclipse.smarthome.core.internal.items.ItemRegistryImpl.getItem(ItemRegistryImpl.java:85) ~[?:?]
        at org.eclipse.smarthome.ui.internal.items.ItemUIRegistryImpl.getItem(ItemUIRegistryImpl.java:837) ~[?:?]
        at org.openhab.ui.basic.internal.render.SwitchRenderer.renderWidget(SwitchRenderer.java:85) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.renderWidget(PageRenderer.java:194) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:160) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processChildren(PageRenderer.java:181) [bundleFile:?]
        at org.openhab.ui.basic.internal.render.PageRenderer.processPage(PageRenderer.java:124) [bundleFile:?]
        at org.openhab.ui.basic.internal.servlet.WebAppServlet.service(WebAppServlet.java:189) [bundleFile:?]
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [bundleFile:3.1.0]
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:852) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:544) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceServletHandler.doHandle(HttpServiceServletHandler.java:71) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:536) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1581) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1307) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.HttpServiceContext.doHandle(HttpServiceContext.java:293) [bundleFile:?]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:482) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1549) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1204) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141) [bundleFile:9.4.20.v20190813]
        at org.ops4j.pax.web.service.jetty.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:80) [bundleFile:?]
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.Server.handle(Server.java:494) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:374) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:268) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:103) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.io.ChannelEndPoint$2.run(ChannelEndPoint.java:117) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:782) [bundleFile:9.4.20.v20190813]
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:918) [bundleFile:9.4.20.v20190813]
        at java.lang.Thread.run(Thread.java:748) [?:1.8.0_222]
2020-04-01 01:19:50.025 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:50.027 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:50.030 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:50.032 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:50.034 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingMode' for widget org.eclipse.smarthome.model.sitemap.sitemap.Switch
2020-04-01 01:19:50.036 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:50.039 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:50.041 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item CoolingRemBoostTime for widget org.eclipse.smarthome.model.sitemap.                                                                                                                                                 sitemap.Setpoint
2020-04-01 01:19:50.043 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:50.045 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:50.047 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:50.050 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.Setp                                                                                                                                                 oint
2020-04-01 01:19:50.052 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.054 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:50.056 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item CoolingRemBoostTime for widget org.eclipse.smarthome.model.sitemap.                                                                                                                                                 sitemap.Setpoint
2020-04-01 01:19:50.058 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.060 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Setpoint
2020-04-01 01:19:50.063 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.065 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'CoolingRemBoostTime' for widget org.eclipse.smarthome.model.sitemap.sitemap.S                                                                                                                                                 etpoint
2020-04-01 01:19:50.067 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item SystemType for widget org.eclipse.smarthome.model.sitemap.sitemap.F                                                                                                                                                 rame
2020-04-01 01:19:50.070 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:50.073 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve visibility item FanCtrl for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:50.075 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'FanPin' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:50.077 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'FanPin' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:50.080 [ERROR] [ui.internal.items.ItemUIRegistryImpl] - Cannot retrieve item 'FanPin' for widget org.eclipse.smarthome.model.sitemap.sitemap.Text
2020-04-01 01:19:50.082 [WARN ] [basic.internal.render.SwitchRenderer] - Cannot determine item type of 'FanMode'

[More lines omitted due to post size limit]

Do they make any sense?

rlkoshak · April 1, 2020, 4:47pm

They make sense in I know what they mean but they don’t make sense in that they are happening.

What they mean is you’ve opened BasicUI but it doesn’t think any of the Items exist. But that shouldn’t be the case. I’ve seen something like this before but it only occurs on the first start of OH immediately after a clear the cache. One or two restarts of OH usually corrects the problem, but I never saw the problem on the HestiaPi so am surprised. Are you running this on an RPi 3 or RPi 0? Maybe it still is a problem on the RPi 3…

Anyway, the errors are not really all the meaningful in getting to the root cause of the problem. They all come from BasicUI not seeing the Items.

Look at /var/lib/openhab2/jsondb. Are any of the files there zero sized? In particular I’m worried about the Items file. I suppose it’s theoretically possible that something went wrong with that file somehow. I have seen that file corrupted by a power outage when the RPi can’t cleanly power down, but any file can be corrupted in that situation. The file sizes should be close to the following (I’ve made some minor changes for my production HestiaPi):

pi@hestiapi:~ $ ls -lh /var/lib/openhab2/jsondb
total 324K
-rw-r--r-- 1 openhab openhab  709 Mar 26 09:30 automation_rules_disabled.json
-rw-r--r-- 1 openhab openhab  89K Mar 26 12:08 automation_rules.json
drwxr-xr-x 2 openhab openhab 4.0K Mar 26 12:08 backup
-rw-r--r-- 1 openhab openhab    2 Mar 26 09:30 org.eclipse.smarthome.config.discovery.DiscoveryResult.json
-rw-r--r-- 1 openhab openhab  32K Mar 26 11:47 org.eclipse.smarthome.core.items.Item.json
-rw-r--r-- 1 openhab openhab 3.0K Mar 26 09:30 org.eclipse.smarthome.core.items.Metadata.json
-rw-r--r-- 1 openhab openhab  30K Mar 26 09:30 org.eclipse.smarthome.core.thing.link.ItemChannelLink.json
-rw-r--r-- 1 openhab openhab 142K Mar 26 09:30 org.eclipse.smarthome.core.thing.Thing.json
-rw-r--r-- 1 openhab openhab    2 Mar 26 09:30 StorageHandler.For.OAuthClientService.json
-rw-r--r-- 1 openhab openhab    2 Mar 26 09:30 thing_status_storage.json

In PaperUI do you see Things, Items, and Rules listed in their respective menus?

This is really odd behavior but without further info it’s hard to tell what is going on. I do note the lack of the log statement: “OH is loaded, kicking off initialization, Initialized == NULL”. That means the Rules DSL rule in default.rules failed to run. Disturbingly though it failed to run or errored out silently without generating any error log messages.

Modify that log statement to git rid of the last part where we try to log out the value of Initialized. I wonder if the Rule just fails silently if you try to access an Item that doesn’t exist, which leads us back to what on earth happened to the Items?

atd · April 9, 2020, 7:51pm

Finally I could test this. I added:

In Paper UI

Channel HeatingMode
MQTT State topic: hestia/local/stat/heatingmode
MQTT Command topic: hestia/local/cmnd/heatingmode

Channel HeatingModeFollow
MQTT Command topic: hestia/local/stat/heatingmode

In .things file

String HeatingMode { channel="mqtt:topic:21501fcc:heatingmode", autoupdate="true", channel="mqtt:topic:21501fcc:heatingmodefollow" [profile="follow"] }

After saving, I click in the UI (a desktop one) OFF, it works, but when I select Auto ON back, it starts switching endless in the main OH between ON and OFF

Anyway, if I change the channels:

Channel HeatingMode
MQTT State topic: hestia/local/stat/heatingmode
MQTT Command topic: hestia/local/stat/heatingmode

Channel HeatingModeFollow
MQTT Command topic: hestia/local/cmnd/heatingmode

This configuration seems to work in all the cases but one: if I change HeatingMode in HestiaPi’s OH, the main OH does not get updated. This is because in that case, the change is published to hestia/local/cmnd/heatingmode, but hestia/local/stat/heatingmode does not get updated

I am wondering, wouldn’t be easier to use one channel only?

rlkoshak · April 10, 2020, 2:27pm

I don’t think it’s possible to use only one Channel unfortunately. We need to publish the command from the main OH to two topics, cmd and stat, in order for both the UI and the HestiaPi OH to receive it.

I think we need to have a Rule. All of the below are changes to the main openHAB.

Create one Generic MQTT Thing with a Channel subscribed to the stat topic (no command topic). Link this Channel to an Item, I’ll call it HeatingModeState.
Create another Channel subscribed to the cmd topic (no command topic). Link this Channel to an Item, I’ll call it HeatingModeCmd.
Create a proxy Item, I’ll call it HeatingMode. This Item is not linked to anything.
Create a Rule that triggers when HeatingMode receives a command. This Rule will use the MQTT Action to publish the new state to both the cmnd and stat topics.

rule "Send commands to HestiaPi"
when
    Item HeatingMode received command
then
    val mqttActions = getActions("mqtt","<broker Thing ID>") // replace <broker Thing ID with the Thing UID for your Broker Thing

    // Only publish the command if the new state is different from the message currently on the MQTT topic.
    // This will prevent loops.
    if(HeatingMode.state != HeatingModeState.state) {
        mqttttActions.publishMQTT("hestia/local/cmnd/heatingmode", receivedCommand.toString, true) // the last true makes the message retained
    }
    if(HeatingMode.state != HeatingModeCmd.state)  {
        mqttActions.publishMQTT("hestia/local/stat/heatingmode", receivedCommand.toString, true)
    }
end

Create another Rule that triggers when the Items linked to the Generic MQTT Thing change and when necessary update the proxy Item.

rule "Updates from HestiaPi"
when
    Item HeatingModeState changed or
    Item HeatingModeCmd changed
then
    // Only update the proxy if the change is different from the current proxy state. This helps
    // avoid loops.
    if(triggeringItem.state != HeatingMode.state)  HeatingMode.postUpdate(triggeringItem.state)
end

I’ve just typed in the above. I hope to give it a try this weekend but I’m pretty sure this will work. I still need to get my HestiaPi fully integrated with my OH (I’d like to be able to command a boost from my main OH instance and centralize my Google Assistant integration on my main OH). The Rules above are in Rules DSL but I’ll be writing my version in Python. I can post that if it’s helpful too when I get it.

EDIT: Here is a Python version of the above rule that I have tested and it appears to work.

from core.rules import rule
from core.triggers import when

broker = "mqtt:broker:hestiapi"

@rule("Publish Heating Mode Changes",
      description="Publishes new modes to both hestiapi topics")
@when("Item vHeating_Mode received command")
def heatingMode(event):
    action = actions.get("mqtt", broker)
    if action:
        action.publishMQTT("hestia/local/stat/heatingmode", event.itemCommand.toString(), True)
        action.publishMQTT("hestia/local/cmnd/heatingmode", event.itemCommand.toString(), True)
    else:
        heatingMode.log.error("There is no broker thing {}!".format(broker))

@rule("Update Remote Heating Mode Changes",
      description="Synchronize changes made on the HestiaPi itself with the local proxy.")
@when("Item vHeating_Mode_Stat changed")
@when("Item vHeating_Mode_Cmnd changed")
def remoteHeatingMode(event):
    if event.itemState != items["vHeating_Mode"]:
        events.postUpdate("vHeating_Mode", event.itemState.toString())

I’ve done some minimal testing and everything seems to be kept in sync.

HestiaPi · April 17, 2020, 11:41pm

I would add
sudo chmod a+w /home/pi/scripts/;
before the reboot in your commands above as the Temp Unit change script was failing in swapping the bme280[F/C].py with the bme280.py due to permissions.
My other errors seem to be gone once I did everything on a Pi Zero. I was initially doing the upgrade on a Pi 3 for speed but it was messing something up.
Looking good…

rlkoshak · April 20, 2020, 2:16pm

I’ll submit a PR with that change and a couple of other fixes sometime this week.

rlkoshak · April 22, 2020, 9:55pm

PR has been submitted: https://github.com/HestiaPi/hestia-touch-openhab/pull/43

yojuan · April 26, 2020, 12:50am

Just did the upgrade this afternoon, no issues to get things running with the current hestia-touch-openhab repo. What I do notice however, is that the CPU on the PiZero appears to hover between 80-100% all the time (closer to 100% actually) for the java process. Anyone else notice this? Previously CPU load would max out during the boot process but then settle down to <20%.

HestiaPi · April 26, 2020, 6:45am

I believe you tried loading Basic UI before it was fully booted. I think that even having Basic UI loaded on a browser from a previous session tries to reconnect in the background so I suggest fully closing the tabs before a restart. It is a bug Rich is aware. Please try my suggestion and report back