That did the trick!
1 Like
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.
Now that you mention it, it was very likely BasicUI the tab was open on.
Thank you for all the work on this! I’ve been meaning to get into openHAB more, but work has kept me very busy the last several months. Only thing I managed was a few cron rules to automatically switch between heating & cooling modes based on the current outside temperature. This helps to deal with California’s sometimes big temperature changes from early morning to afternoon.
Sure, I meant why HestiaPi uses 2 channels. Is that a recommended practice or could it work with just one shared channel?
I want to get back into this, but now I am busy extending HestiaPi to control roller shutters (I will publish my work) and I am wondering if I need 2 channels or just one is enough
Standard practice is to have two channels, one to command and one to update. So, for example, one might have foo/bar/myswitch/command and foo/bar/myswitch/state. To flip myswitch ON send a message to foo/bar/myswitch/command. When the switch changes, the device publishes that to foo/bar/myswitch/state.
This approach works great when you have a device to control and that device can otherwise be independently controlled.
With the HestiaPi temperature setpoints it’s a little more complicated because we are reusing the MQTT topics that are used to drive and be driven by the LCD UI. In this case the LCD UI can issue a command that OH needs to act upon and OH can issue a command that the LCD needs to act upon. Consequently, the setpoint isn’t really separately controllable from the LCD. There is a cyclical relationship there. To keep both openHAB and the LCD in sync, without introducing additional MQTT topics, we need to send the message to both MQTT topics. The one topic to cause openHAB to process the changed setpoint and the other to cause the LCD to show the changed setpoint.
It’s clunky but it works for now until such time that we can come up with a better approach.
tl;dr; for what you are doing I suspect the two topics, command and state, would be sufficient. openHAB would publish to the command topic and subscribe to the state topic. If you configure the Item with autoupdate=false, the Item in openHAB will not change until it receives the message on the state topic.
The danger with using only one topic is it’s easy to end up in infinite loops where openHAB publishes a message to the one topic, the device receives it, changes state, then publishes the new state to the topic, which openHAB receives and processes and publishes back to the same topic and on and on. It can be made to work with on topic, but it usually requires a Rule to break the cycle.
Thank you for the detailed explanation @rlkoshak I understand now the point of having two separate channels.
My doubt know is why they are switched. Why the LCD UI subscribes to cmnd and publishes to stat? I mean, the “myswitch” here (HeatingMode) “lives” in openhab (or the OS). It is the LCD UI the one that is sending commands to change the switch and should read (and display) the state.
If this were the case, it would be compatible with the main openhab instance, wouldn’t it? 
Probably because the topics were set up from the LCD UI’s perspective instead of openHAB’s perspective. So we are commanding the LCD UI and the LCD UI is reporting the state update to OH. So we publish a message to the cmnd topic to change the LCD displayed number and publish a message to the stat topic to cause openHAB to process the new setpoint value.
If we only publish to the cmnd topic, the LCD will show the new number but OH will not be aware of this new value and will continue operating on the old setpoint value.
If we only publsih to the stat topic, openHAB will start operating on the new setpoint value but the LCD will continue to show the old value. This is why the external openHAB instance needs to send the message to both topics so both the OH instance and the LCD get the new value.
Yes, I understand why this is needed with the current setup (and I still have to test your proposal above)
I was just wondering if it would work the other way, because in that case, both the LCD and the main OH would display the stat value
It depends. Is the LCD the only place that the setpoint could be changed? If so than the external OH instance could just subscribe to that one topic. But given that the setpoint can also be changed through BasicUI which will result in only a message on the cmnd topic, both topics need to be monitored as well because the LCD won’t publish the fact that it changed to the stat topic as a result of the message on the cmnd topic.
If it did so, than we could follow the usual pattern and just send messages to the one cmnd topic and just subscribe to the one stat topic. But given the current setup, the external OH needs to monitor both and publish to both.
Ok, I was taking for granted that the HeatingMode would update the stat topic with its new state after receiving a command in the cmnd topic
Trying the upgrade but running apt update I run into a problem:
W: An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://repo.mosquitto.org jessie InRelease: The following signatures were invalid: KEYEXPIRED 1577823874 KEYEXPIRED 1577823874 KEYEXPIRED 1577823874
W: Failed to fetch https://repo.mosquitto.org/debian/dists/jessie/InRelease
W: Some index files failed to download. They have been ignored, or old ones used instead.
but was able to resolve it by resetting the apt resource: https://mosquitto.org/blog/2013/01/mosquitto-debian-repository/
2 Likes
Tried to fix that but git does not allow empty directories. Is there any file that we can place in these 2 directories that will be ignored by OH?
Anything that doesn’t end in “.rules” will be ignored in the rules folder and anything that doesn’t end in “.things” will be ignored in the things directory. So you could add a readme.txt that says “This is where rules go” or something innocuous like that and OH will ignore it.
I would like to get back and test these changes. As the pull request was merged, I guess I just test the ONE branch. Is this right?
Yes, that’s right
Sorry for the tardy reply, I was offline for one glorious week. 
This thread has some activity diagrams (incomplete as you progress down the drawings) showing how the individual Rules interact with each other. In general there is a cascade:
- rule process sensor reading or setting (e.g. setpoint or mode) that may change the state of the devices (e.g. Process sensor reading, Mode changed, Boost, etc.) and determines which device(s) may need to respond to the change
- another rule determines if a device needs to change state (the “Check” rules, e.g. Heating/Cooling Check)
- another rule actually implements changing the state of a device (the “Control” rules, e.g. “Heating Control”
- finally a rule maps device to GPIO Item which flips the right relay.
Having the Rules flow like this allows for a reduction of duplicated code and an improvement in opportunities for error checking. But over time I’d like to simplify this where I can.
This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.