Closed rkoshak closed 4 years ago
I apologize for the extra commit. I discovered a bug that occurs on a restart of the machine. The change is to allow sensor updates to process even if the system is starting up (i.e. remove the if(initializing) return; from the Process Sensor Changes Rule.
Otherwise, if the reading is holding steady nothing will work until the temp actually changes which could be quite some time. There is already a check in place to avoid turning on or off anything until the system is done booting up.
OK, there are other problems with reboot. I'm working on another commit. Until I figure this out consider this a WIP.
OK, this latest check-in should be fine. The problem before was the new sensor readings were being ignored while the initialization Rule was running. But the sensor may not change enough to generate a change every ten seconds. In fact, if the temp is held pretty steady it could be a long time before there's a change and consequently the proxy Items never update causing the rules that need to check the current temp (or humi) to fail because the proxy was NULL.
The other problem was even if the sensor readings are not ignored and all the proxies are updated, if the temp changed during the initialization rule that change wouldn't have been processed. As a result we would have to wait until the temp changed again by a large enough amount before, for example, the heater would turn on even if the temp was below the setpoint while the initialization rule was running. So we command the proxy and the PrevReading Item at the end of initialization which will kick off the "Temp/Humidity or setpoint changed" rules which will immediately activate the devices (or not) based on the current mode.
This should be ready for review now. It's been running on my spare HestiaPi for about a week now and running on my production one for the past 24 hours or so (it was transferring it to my production system that I discovered the reboot problem).
A rewrite of the Rules to remove duplicate code, add some logging and some error checking.
The new Rules should work almost exactly the same as the old code. There were a couple of bugs in the old code (e.g. referring to Items that do not exist, the rule never would have worked).
At the top of the file you will find some HashMaps containing configuration information including default values for settings and mapping between device Pins and GPIO pins. The allows the code to be generic and we look up the appropriate mapping when a device pin changes.
I added an initializing flag to prevent Rules from running before the System started Rule runs. This allowed the removal of a lot of checks and initialization logic from the functional Rules.
Each device type has two lambdas, one that decides whether or not the device needs to be turned ON based on the sensor readings (if applicable) and the device mode. The other actually turns the device(s) on or off when called. The 2nd stage heating is encapsulated in this second lambda. The lambdas prevent the turning on/off of devices that are not appropriate for the SystemType.
Initialization was updated to populate the lambda Maps (we can't do that until we are in a Rule.
PreviousModes have been moved to Items that we can restoreOnStartup and more easily access by name.
On initialization, and devices that were in Boost mode are restored to their previous Mode.
Merged the Temp proxy update logic into one Rule.
Merged the DevicePin to PinXX mapping to one Rule and the Map previously discussed.
Made the Sensor reading Rule more generic and when it runs, only the Items for the sensor that changed get updated.
The Rule that triggers when the temp or setpoint changes now calls the appropriate lambdas to decide what to do.
The rule that triggers when the humidity or setpoint changes now calls the appropriate lambda to control the humidity.
The Mode Rules have been merged into one and the appropriate lambdas are called when they change.
All the Mode Items were added to a Group and the MainSwitch OFF Rule just needs to sendCommand to the Group. The Mode Rule will handle turning off the pins.
Boost mode has been completely reworked to make it generic and simpler. When any device enters boost mode, it's turned on (unless already above the setpoint) and a new RemBoostItem is updated with the current value of the BoostTime Item. This kicks off a RemBoostTimeChanged Rule which is where the countdown timer is implemented. It counts down one per minute and when it gets to zero turns off the Boost and returns to the previous mode. The RemBoostTime Item can be changed or the BoostTime Item changed and it will extend or reduce the boost time accordingly. The Sitemap was changed to switch to the RemBoostTime Item to show the time remaining. I think the LCD UI needs to be updated as well.
The rest of the Rules have fewer over all changes with just some cleanup, logging, and error checking added. Because all the Rules are in one file now, the SystemType Rule no longer copies the .rules file around.
All of the Rules that map an Item to an LCD MQTT topic Item have been merged into one generic Rule.
As mentioned all the Rules are now in the one file so hvac.rules and generic.rules have been removed and default.rules added.
You will find a new file in scripts called TestChecklist.txt. This shows the tests and verification steps that I performed to test out these new Rules. I tried to be pretty thorough. But if I misinterpreted the way something is supposed to work, you will see that in the checklist.
I'm pretty sure I exercised every line of code so it should work as expected. But please let me know if I missed something or missinterpreted something.
I help in some commented out code. I wasn't sure what it was all about.
I've some TODOs scattered throughout the code with some questions about whether certain things are still needed (e.g. the reboot after changing the SystemType.
Solves #26 and #10
Signed-off-by: Richard Koshak rlkoshak@gmail.com