Could it be that you skipped this note?
No, I waited 
Besides I connected via ssh and ran htop to ensure everything was done before I connected to the WebUI
What it did happen is that it was opened when I rebooted the second time (after changing EU and C settings)
I believe the Web UI tries to reconnect in the background so this may cause the issue. I have slightly edited the note above…
I just repeated the process:
service openhab2 stop
rm -r scripts
cp -r hestia-touch-openhab/home/pi/scripts/ scripts
sudo rm -r /var/lib/openhab2/
sudo cp -r /home/pi/hestia-touch-openhab/var/lib/openhab2/ /var/lib/openhab2
sudo chown -R openhab.openhab /var/lib/openhab2
sudo rm -r /etc/openhab2
sudo cp -r /home/pi/hestia-touch-openhab/etc/openhab2/ /etc/openhab2
sudo chown -R openhab.openhab /etc/openhab2
Edited scripts/systemtype to set EU
Edited scripts/tempunit to set C
I ensured no tab is opened with WebUI and rebooted
This time, openhab boots and the touch UI shows EU interface but temperature in F degrees
This is the openhab.log
2020-08-09 02:49:37.743 [INFO ] [thome.core.items.ManagedItemProvider] - Finished loading the items which could not have been created before.
2020-08-09 02:49:46.555 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at http://x.x.x.x:8080
2020-08-09 02:49:46.570 [INFO ] [.dashboard.internal.DashboardService] - Started Dashboard at https://x.x.x.x:8443
2020-08-09 02:51:20.482 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.sitemap'
2020-08-09 02:51:22.414 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'mapdb.persist'
2020-08-09 02:51:23.118 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.items'
2020-08-09 02:51:25.995 [INFO ] [thome.model.lsp.internal.ModelServer] - Started Language Server Protocol (LSP) service on port 5007
2020-08-09 02:53:50.224 [INFO ] [el.core.internal.ModelRepositoryImpl] - Loading model 'default.rules'
2020-08-09 02:54:06.475 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Error during the execution of startup rule 'Kick off initialization': null
2020-08-09 02:54:07.676 [INFO ] [el.core.internal.ModelRepositoryImpl] - Refreshing model 'default.rules'
2020-08-09 02:54:23.842 [INFO ] [.model.script.initialization.kickoff] - OH is loaded, kicking off initialization, Initialized == NULL
2020-08-09 02:54:24.101 [INFO ] [.model.script.initialization.kickoff] - Commanding Initialization Rule to start
2020-08-09 02:57:54.203 [WARN ] [core.thing.internal.ThingManagerImpl] - Initializing handler for thing 'mqtt:broker:mosquitto' takes more than 5000ms.
2020-08-09 02:58:08.153 [INFO ] [.transport.mqtt.MqttBrokerConnection] - Starting MQTT broker connection to 'localhost' with clientid mosquitto
2020-08-09 02:59:46.900 [INFO ] [eclipse.smarthome.model.script.wanip] - WAN IP changed to x.x.x.x
2020-08-09 02:59:47.682 [INFO ] [openhab.ui.paper.internal.PaperUIApp] - Started Paper UI at /paperui
2020-08-09 03:00:03.591 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:00:05.654 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:00:07.668 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:00:09.837 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:00:10.216 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:00:11.591 [ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-persistence-mapdb, openhab-ui-restdocs, openhab-binding-exec, openhab-binding-mqtt, openhab-transformation-map, openhab-ui-basic, openhab-misc-ruleengine, openhab-transformation-regex, openhab-ui-paper, openhab-binding-gpio1': Error restarting bundles:
Exception in org.eclipse.smarthome.io.rest.sse.internal.SseActivator.start() of bundle org.openhab.core.io.rest.sse.
2020-08-09 03:00:40.711 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:01:11.233 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:02:15.481 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:02:46.240 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:03:11.611 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:03:17.035 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:03:47.627 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:04:12.025 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:04:18.264 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:04:48.570 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:05:12.381 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
2020-08-09 03:05:18.971 [ERROR] [internal.handler.ScriptActionHandler] - Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14
Switching lines
print "Temperature : ", temperature, "C"
# print "Temperature : ", (temperature*1.8)+32, "F"
Fixes the F issue
Through I still get Script execution failed: TypeError: items["Previous" + device + "Reading"].floatValue is not a function in <eval> at line number 14 messages, as mentioned in Interoperability with other OpenHAB instance
After another reboot, those messages go away.
Everything seems to be 
Thank you for all the work! Version 1.2 looks great! 
Is the file writable by openHAB? Try changing it from the app/web UI and check its contents. It doesn’t need reboot (just a few seconds) so no worries.
Congrats to y’all on this new release.
As this is a release targeted at developers first, please report here if you find something wrong but only if you have clear reproducible (and maybe timed) steps we can follow.
This error is occurring because PreviousTempReading (or one of the other sensors) has a NULL or UNDEF state. I need to add a check for that to prevent the error when that occurs. That rule shouldn’t even attempt to run when this happens.
But the tl;dr of it is you can ignore this error. It does point to some sort of error happening in the initialization function perhaps because I think these get set to 0 in that function. So I would expect to see these errors when OH is starting up and the initialization function hasn’t completed but sensor readings are coming in. And indeed the logs in post 9 do not show the “ready to operate” log message that happens at the end of the initialization function.
The error about failing to install add-ons can explain some of the other behaviors. The system requires mapdb to be installed in order to remember your settings on an openHAB restart. If it’s still failing to install that means that it will never remember the changes and act like it’s the first boot every time.
The rest sound like permission problems as HestiaPi indicated.
Those changes should have been made when you switched from US to EU mode and/or from Temp_Unit F to Temp_Unit C. That implies a permission problem too.
I’m glad you are up and running. If anyone else sees the same behaviors please post here so we can try to find a pattern and fix it.
No, the file is not writable by openhab. I just follow the instructions:
cp -r hestia-touch-openhab/home/pi/scripts/ scripts
So this will probably be already fixed in the released image
Took me a while to install this update, worked first time and looks great. Congratulations and thank you for the hard work.
Can someone explain how COMFORT/ECO works with the Comfort Range setting? I notice in Eco mode the thermostat LCD displays the Comfort Range setting in the bottom right corner, but in Comfort mode it just displays Comfort Mode. What is the actual “swing” range in Comfort mode?
Now to apply all my customizations…
EDIT: Found it
In the Heating/Cooling Check rule then action:
var comfHyst = DEFAULTS.get(items["TempUnit"]+"_COMFORT_DEF");
var ecoHyst = items["Comfort_Value"].floatValue();
var hysteresis = (items["Comfort_Mode"] == "COMFORT") ? comfHyst : ecoHyst;
And in /etc/openhab2/automation/lib/hestia/defaults.js:
11:DEFAULTS.put("C_COMFORT_DEF", 0.5); // COMFORT mode hysteresis in C
20:DEFAULTS.put("F_COMFORT_DEF", 1.0); // COMFORT mode hysteresis in F
So in Comfort Mode, the temperature hysteresis/swing range is fixed to 0.5C/1F, and in Eco Mode it is whatever you set it to on the Settings page.
1 Like
Just wanted to thank you for version 1.2. I had tried the stock version earlier, and it seemed to work ok, but my touchscreen did not work. After getting a new touchscreen I decided to to go with this version. I was very happy to finally see the boot and then get the normal graphics. The touchscreen display works! But the touch is wonky. I am trying to figure out if the axes are swapped or something.
I have been thinking about ways to change the temperature during the day and am thinking of using cron, so I have a bit of digging to do.
I look forward to your next release.
Thank you!
Hello Herber,
I broke off my reply about the LCD to another thread.
Regarding the temp change with cron you can simply publish to the appropriate MQTT topic with the command mosquitto_pub and the right params. Please note that it can only support absolute values and not +1 changes or similar. mosquitto_sub can query the last value of the topic you want, apply your modification yourself in a script or something and call mosquitto_pub with the correct absolute value. Then simply call the script from cron and let it do the rest.
Please share your results in a separate topic if you come up with a complete “solution” so that other benefit from your work.
Glad you found it. I’ve been off the forum for awhile but shouldn’t miss these messages now. If you have any other questions let me know.
Topic(s). In order for both the LCD to update with the new setpoint and openHAB to process and apply the new setpoint it needs to be published to:
Heating:
hestia/local/cmnd/setmintempsetpoint: Tells the LCD to show the new setpoint for heatinghestia/local/mintempsetpoint: Tells OH to process and apply the new setpoint for heating
Cooling:
hestia/local/cmnd/setmaxtempsetpoint: Tells the LCD to show the new setpoint for coolinghestia/local/maxtempsetpoint: Tells OH to process and apply the new setpoint for heating
Another approach would be to use a cron triggered rule. For example, if you wanted to set the max setpoint to 72 at 08:30 you can do so through PaperUI. I’m 90% positive this works but you might want to test it out before spending a lot of time setting up a complicated schedule.
Create the rule
Navigate to http://<address of HestiaPi>:8080 and click on PaperUI.
Select Rules on the left hand side.
Click the blue + icon at the top to create a new rule.
Give the rule a meaningful name and description.
Create the trigger
Click the blue + icon next to “When”
For the trigger type select “It is a fixed time of day”.
Put in the time.
Create the action
Click the blue + icon next to “then…”
Choose “Send a command” for the type
Select MinTempSetpoint from the list of Items and 68 (the temperature you want to set the heater to at 08:30).
Optional, type of day
There are two options here.
It is a certain day of the week
Click the “but only if” + icon.
Choose “It is a certain day of the week” from the list.
Select the days you want this rule to be active.
NOTE: I’m pretty sure this actually does not work in this version of OH.
Ephemeris
In PaperUI (open in another tab) select Configuration → System and scroll down to Ephemeris.
Fill in the information for what days of the week are weekend days and enter your country, region, and if applicable city to load in the default set of “bank holidays” for your area.
Return to the rule.
Click on the + icon next to “but only if…”
Select “It is a holiday”, “It is a weekend”, “It is a weekday” as appropriate. If you want the rule to run under multiple conditions (e.g. holidays and weekends) create another “but only if…”. You can optionally set an offset (e.g. two days before a holiday).
The Item is already set up to forward the command to the LCD so you don’t have two worry about the two topics if you use mosquitto_pub.
See Actions | openHAB for how to further customize ephemeris with additional daysets and custom holidays.
NOTE: I’ve never tested this and if it doesn’t work, I can show how to do this another way using the “A script evaluates to true” as the condition instead of ephemeris or the “its a certain day of the week”.
Repeat
Once the first rule is created and tested you have two options for creating the rest. You can just create each needed rule one by one by following the steps above. Or you can copy and paste using the REST API.
If not already installed, install the REST API from the UIs tap in PaperUI. Navigate to the http://<address of hestiapi>:8080 and select REST API from the list.
Scroll down to and click on “rules”.
Click on “Gets the rule corresponding to the given UID.”
Copy the rule UID (that string of random looking characters) into the ruleUID filed and click “try it out”.
Copy the JSON that was returned to a text editor. Modify those parts that need to be changes (name, description, times, and temperature to command).
Click on “Creates a rule” and paste in the edited JSON into the “body” field and click “try it out”. This will create a new rule with the changes you made.
1 Like
Thanks for finding this. Might be more intuitive to have the settings page “Comfort Range” read as “Eco Range”, I had it set to Comfort mode thinking it would float within the range set and noticed it kick the heat on when the temp was 1 degree off and thought there was something broken with the setting.
1 Like
This release has worked well. Thank you.
Is a new release planned?
Would it be based on openhab 3?
That is the plan but due to Covid we cannot realistically put a date on it. Everything is so much slower these days…
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.