Jsondb Configs

[rkoshak]

This PR includes all the changes made to move as much of the configs as possible to JSONDB. Please ask questions if you need help understanding anything done or how to find the configs or anything like that.

Solves #37 and #17 and it includes the first part of #12 (I have the Thing defined but not yet the Rule to process the values and figure out which one to use in making the heating/cooling/humidifier decision). It also sets the stage to addressing #11 as the binding, config, and Rule can all be done through PaperUI.

These configs will require OH 2.5.3-1. Changes in the way everything works:

• Almost all calls to executeCommandLine have been moved to Exec binding Things. Those we need to kick off on command have Items linked to the Run Channel to command the script to run.

• There is significantly more error checking in US mode to prevent the Fan from being turned OFF while heating or cooling and to prevent both heating and cooling from ever turning on at the same time.

• Increased logging that is meaningful and stopped logging that is less meaningful. Added comments and examples to the logger config to turn various loggers on/off. When ever it needs to turn on/off a device there are a handful of logging statements made to openhab.log saying what it's doing and why. events.log is turned off to save the one+ logging statement per second it would log otherwise. Rules have many debug level logging which can be turned on when needed with instructions in the logging config for how. There are also instructions for how to turn back on events.log in the config as well. All the custom logging stuff is at the bottom of the logging cfg file.

On my HestiaPi, it's now almost exactly 10 minutes from white screen on the LCD until it's fully functional, give or take half a minute depending on various random stuff that might happen during the boot.

I'm still working on the diagrams showing how events bounce from one rule to the next. At a general top level:

• Mode changed: This is called when ever any device's mode changes, it will call the corresponding Check Rule.
• Sensor Setpoint Changed: This is called when a sensor reading changes enough for PreviousXReading to change or a Setpoint changes, it will call the appropriate Check Rule based on the sensor/setpoint that changed (and SystemType).
• X Check: These rules are called to decide whether or not a device needs to turn on or off because of some change (Sensor reading, Setpoint, or Mode). There is one Check Rule per device though Heating/Cooling share the same Rule.
• X Control: There is one of these Rules per device type. These implement the error checking and logic necessary to actually turn ON/OFF the device. This is the Rule where 2nd stage Heating is implemented. The Heating and Cooling Control Rules also will turn on the Fan by setting the FanMode to AUTO which will trigger the Mode changed Rule for the Fan which in turn calls Fan Check which calls Fan Control.
• Map Pin to GPIO: To turn on or off any device the Control Rule sends a command to a DevicePin Item. This triggers this Rule which implements some additional checking to prevent the fan from being turned off while heating/cooling and then calls the appropriate GPIO Pin Item.
• If heating/cooling is running, you cannot turn the other one ON using Boost Mode.

So, for example, if Heating mode is ON and the temp changes where the heater needs to turn on the flow through the Rules would be:

1. PreviousTempReading Item changes
2. Sensor Setpoint Changed Rule triggers and sees that the current temp is below the setpoint so commands HeatingCheck to ON.
3. Heating/Cooling Check Rule triggers and determines whether or not the heater needs to be turned on or off. In this case it needs to be turned on so it commands HeatingCtrl to ON. This is where you would implement something like hysteresis or multiple setpoints (e.g. a min and max setpoints to control the heater/cooler based on two setpoints.
4. Heating Control Rule triggers which makes sure the MainSwitch is ON and if in US mode turns the Fan on by setting FanMode to AUTO and turns off the Fan controls on BasicUI by commanding FanCtrl to OFF. Finally it waits ten seconds and commands HeatingPin to ON. a. Mode changed triggers when FanMode changed to AUTO. This rule records to previous state and then command FanCheck to determine if the fan needs to be turned on. b. Fan Check Rule triggers and sees that the fan needs to be turned ON because the mode is AUTO. It command FanModeCtrl to ON. c. Fan Control Rule is triggered and does some error checking before sending ON command to FanPin. d. Map Pin to GPIO is triggered when FanPin is commanded to ON and it commands the appropriate Pin Item to ON to turn on the Fan.
5. Map Pin to GPIO is triggered when HeatingPin is commanded to ON which commands the appropriate Pin Item to ON to turn on the Heater.

All of the devices follow the same path through the Rules.

A little about how the JSONDB Rules work. Unlike Rules DSL, each Rule has three sections:

1. When...: A.K.A Triggers, this is where the Rule Triggers are defined.
2. but only if...: A.K.A. Conditions, this is where you can define the conditions under which the Rule will execute. Almost all of the error checking and safeguards are implemented here (e.g. this is where we check to see if heating or cooling is ON and if it is prevent the Fan from turning OFF).
3. then...: A.K.A. Actions, this is where the logic of the Rule is defined. The logic is usually relatively simple since it doesn't have to implement any error checking.

You will see lots of stuff like conditions that prevent the HotWater Rules from running unless the SystemType is EU, the Mode changed rule from running unless the Initialization Rule has completed as well as full JavaScript code that performs complicated checking and error logging. You will also see some error correction in this section. For example, if you attempt to set TempUnit to something not "C" or "F" it will revert the change back to the previous value and the Rule to handle a TempUnit change will not run.

At least to start, it might make sense to review the Rules through PaperUI. Then compare what you see there to the JSON which you can get to through the REST API or by looking at the automation.json file in a text editor. Seeing the two side by side will help you interpret the JSON more easily.

I'm still working the drawings that depict the flows above for each of the device types as well as how Boost works. I'll add sections to the docs with those drawings when the time comes. I'm using Draw.io so the drawings are saved as XML and be checked in here and kept up to date as needed. I figure though we don't want to add them and other docs to the wiki until we get closer to releasing these changes.

Let me know if there are any questions, comments, or concerns deploying or reviewing.

I have not updated the packaging script nor have I removed the openhabloader.sh script.

I recommend leaving this PR open until you have done a thorough review and testing. That way I can add the fixes and requested changes here on this branch without messing with the ONE branch until we are ready.

Signed off by Richard Koshak rlkoshak@gmail.com

[rkoshak]

I should have done this before. I transitioned this new version over to my production HestiaPi and discovered a few very important files didn't get checked in (exec.whitelist fior example).

I've also discovered that the Language Server Protocol bundle still comes up so that is something that will need to be done after upgrading to OH 2.5.3-1 but before creating the SD card image.

1. SSH to the karaf console: ssh -p 8101 openhab@localhost
2. Password is habopen
3. Wait for a prompt.
4. bundle:list | grep Language

165 │ Active │  80 │ 2.5.0                   │ openHAB Core :: Bundles :: Language Server

The first number may be different.

5. bundle:uninstall 165
6. bundle:list | grep lsp

104 │ Active │  80 │ 0.8.0.v20190822-0801    │ org.eclipse.lsp4j
105 │ Active │  80 │ 0.8.0.v20190822-0801    │ org.eclipse.lsp4j.jsonrpc

Again, the first number may be different.

7. bundle:uninstall 105
8. bundle:uninstall 104

I'll research what I can do to get it excluded permanently through changes to the userdata configs and there is already an issue open to make this something easier to configure over on the openHAB project.

[gulliverrr]

Although I got some minor issues here and there I merged it in order to give more people the chance for better testing due to the extend of the changes.

[rkoshak]

Please do open new issues for the the minor issues you saw and I'll see if I can address them.

[gulliverrr]

I used a fresh v1.1 HVAC image and then applied these commands to upgrade to your version. Would it help if I provide an updated image file to reproduce the errors?

[rkoshak]

Perhaps, but first try a reboot. Watch openhab.log as it comes back online (I've been sshing in to the machine as soon as the loading screen shows up on the LCD and opening a tail -f on the openhab.log and in another terminal an htop just to have an idea where it is in the boot process. Don't bring up BasicUI until you see "Kicking off initialization" in the logs and/or the LCD screen switches to the functional screen.

Do the errors you posted in that other thread persist? Are there any other errors?

Unfortunately the errors in the forum thread don't actually tell me what may be wrong beyond the fact that the sitemap doesn't think there are any Items.

Just let me know when/where you post the image and I'll take a look at it as well.

[gulliverrr]

@rkoshak should we move to newly released 2.5.4 while at it? I see why not. I'll test it on my setup although I doubt it will break anything.

Do the errors you posted in that other thread persist? Are there any other errors?

I avoided using Pi 3 for the upgrade and first couple of boot and also kept my Basic UI browser tabs closed as they may try to reconnect although I'm not hitting refresh or so. I'll make a new image file tomorrow to help testing. I removed Language Server Protocol bundle too. ToDo:

• Fix OH to specific version (2.5.3 or 2.5.4)
• Upgrade to stock Mosquitto (or not)
• Update the upgrade script

Not sure if I'll touch kiosk-xinit.sh and packitupandgo.sh just yet.

Any other ideas?

[rkoshak]

There was some sort of bug fixed in the MQTT binding so it's a good idea to move. I'm of the opinion that we should try to keep up with the OH versions at least until we have a release. I've not tested with it yet but plan on doing so once I figure out the setpoint bouncing problem.

See my reply at the issue you linked for Mosquitto. I'm not sure what link you brought up but apt is showing the latest version of Mosquitto is 1.6.7 and websock support was added in 1.5.1. The currently installed version of Mosquitto is 1.4.9.

NOTE: I have no idea if the websockets work the same between the compiled in stuff in 1.4.9 and what comes with 1.6.7. There may be work required to update.

I think the list you have sounds good. I can't think of anything else that might need to be done.