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 
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.
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
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.
To upgrade you would follow the following steps:
sudo apt updatesudo 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./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 rebootI 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).
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.
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!
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.
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.
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?
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?
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?
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.
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
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.
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…
I’ll submit a PR with that change and a couple of other fixes sometime this week.
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%.
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
That did the trick!
Thanks for giving it a try!
Yep, I’m aware of it but am not sure what to do about it. I will say that it doesn’t always cause problems and it usually doesn’t cause that extreme of a problem. Usually it just kept the overall system load high enough that the boot script that starts everything up never kicked off the initialization process.
Is this repeatable for you? I’m not able to reliably reproduce it since moving over to the JSONDB configs. Did you reboot after closing BasicUI, or did you just stop BasicUI, or perhaps do as little as refreshing the page on BasicUI? Did this seem to delay the boot time or was the boot able to finish and then the CPU load spiked (or never dropped down)?
Once it loads and everything settles down, with BasicUI connected I usually see the CPU bouncing between 10% and 20% with rare spikes above 30% (probably caused by Rules). Without BasicUI attached I see it hovering between 6% and 12% with the same occasional spikes.
Any information you can provide will go a long way towards figuring out the root cause and solving the problem.
I did notice that while the CPU % was high, the CPU temperature didn’t go up? 
Possibly a sign that some process is looping but not doing much.
I actually started all over by shutting down all openHAB browser tabs, deleting what I copied before and re-installing. After rebooting load was <20%. I’ll try a reboot with a PaperUI open in the browser to see if it happens again. I’ll be better about recording exactly what I do, my job is as a software developer, usually don’t have to do QA!
Minor and probably unrelated annoyance: After the install the temp setpoint is at 32F. It is PAINFULLY slow to increment it up using the controls. Basically click, then wait forever while it bounces back and forth, click & repeat. If you click several times the thermostat locks up with the setpoint temp oscillating. I ended up setting it using the REST API.
It’s unusually hot in Southern California right now, and with the quarantine everyone at home wants to kill me for messing with the thermostat 
I’ve never seen the problem with PaperUI, only with BasicUI. If it’s happening with PaperUI this is something new I’ve not seen before.
That should be fixed in PR #43 which was merged five days ago. You can confirm if you are running with the fix by looking in PaperUI → Rules → Synchronize Temp Proxies → click to cog icon under “then…” and the code should look like this:
var OPENHAB_CONF = Java.type('java.lang.System').getenv('OPENHAB_CONF');
load(OPENHAB_CONF + '/automation/lib/hestia/utils.js');
// If the change is from MyTempProxyF or MyTempProxyC, forward the new value
// to MyTempProxy
var toItem = (event.itemName.endsWith("F") || event.itemName.endsWith("C")) ? event.itemName.substring(0, event.itemName.length-1) : event.itemName+items["TempUnit"];
createTimerSecs(1, function() {
if(items[toItem] != items[event.itemName]) {
logDebug("tempproxy", "Commanding " + toItem + " with " + items[event.itemName]);
events.sendCommand(toItem, items[event.itemName]);
}
});
The big difference is that Timer which waits a second before processing the temp updates. So if you press the button several times in a second, the LCD should update itself but the Rules won’t actually process the new setpoint until a second has passed. This avoids that setpoint bounding. If your code looks like the above, than you have the latest code and despite my best efforts I didn’t manage to fix the problem after all. 
This whole Rule will go away when I move to use Units of Measurement. At that point everything can be C in the Rules and we can convert to F where we need to instead of maintaining all of these proxy Items and multiple copies of the bcme script and such. That should simplify the Rules, eliminate this problem Rule entirely, simplify the python scripts and more. And for those of us who use the vastly superior F ( 
) it’s still no big deal as we can still do so in the Rules.
Been there, only it was a couple months ago still in the middle of winter and one of my edits broke the thermostat over night. The house got down to 40 degrees. No more testing stuff in production.