release v3.8

[IgorYbema]

This fixes an issue in v3.7 while saving settings.

v3.8 will include the v3.7 changes:

• disable wifi hotspot in settings
• move from double reset as factory reset method to 10 sec boot button press and hold
• adding a few heatpump types in type discovery
• fix rules variables print to console
• changed heatpump data in rules is now updated directly (bug)
• NTP resync works also if during reboot there was no internet/wifi
• website table refreshing is now using the JSON output and not a hard coded html output anymore
• small urldecode issue causing a crash (bug)
• JSON output is chopped into more chunks each webserver loop making it less memory hungry
• optional PCB emulation topics are now (finally) visible on the webgui

[McMagellan]

Feedback V3.8 Egyras Build138 Signature "550efd7"

When testing 3.8 I saw the following in the debug log file: It starts with the FW update.
709bputty.log

I use the new CoPilot Rule Version4. After restarting, the variables #Delta and #TOP27Backup are set to NULL. These 2 variables are first supplied with values ​​from Jeisha in Timer11. Therefore, I only call Timer11 after 10 seconds from the “System#Boot” so that there is time for the first synchronization with the HP.

The log file shows that Timer11 should be executed in 10 seconds from System#Boot (line 317). Since timer 11 is called immediately afterwards and the Jeisha data is not yet available by then, this error occurs. I can see from the timestamp that the 10 seconds are ignored.

It is also strange in line 328 that the value of #Delta is displayed correctly with the initial assignment from System#Boot. The next time it is displayed on line 354, a space is missing and the value is NULL.

Rules code excerpt from Timer 11:
After a refresh using rule Nr5, the #Delta variable runs correctly again.

   #Delta = @Main_Outlet_Temp - @Z1_Water_Target_Temp;
   if @Room_Holiday_Shift_Temp >= 0 && @Room_Holiday_Shift_Temp <= 10 then
     #BoniPool = @Room_Holiday_Shift_Temp;
   else
     #BoniPool = 2;
   end
   if @DHW_Holiday_Shift_Temp >= -10 && @DHW_Holiday_Shift_Temp <= 10 then
     #Periode = 160 + (10 * @DHW_Holiday_Shift_Temp);
   else
     #Periode = 160;
   end

[IgorYbema]

Wait before release v3.8. You reverted the v3.7 fix from yesterday but that fix was ok :)
There was another bug in v3.7 why I needed you to pull away the v3.7 completly.
Now this v3.8 is missing the v3.7 fix from yesterday which I am adding now again...

[IgorYbema]

@Egyras this build is now good... please make this a release v3.8

@McMagellan nothing got changed for the rules part between your tested version v3.7 and this one so I can't say what is going on but I understand it is not a big thing

[McMagellan]

For me it is clear what happened.
After a reboot with loading of an existing ruleset, the first timer does not have a correct initial value and is therefore executed immediately instead of the scheduled time. The reference time to which the timer time is based is therefore not correct. The timing structure is unclear at this point because no ntp synchronization has taken place yet. In any case, the uptime in "stats" shows 17 seconds while the time is 5 seconds.

Line 316 -> System#Boot
Line 317 -> Run timer 11set to 10 seconds.
Line 343 -> Timer 11 is executed approximately 2 seconds later, judging from the current time.
Line 341 -> shortly before, a request is sent to the panasonic for the first time.
Line 373 -> The @- variables are now available in Heishamon, but the timer with the calculations has already been processed.

This also means that the grayed out calculations in the rule of Timer 11 are all carried out incorrectly because there is no "True" in relation to a variable that is not supplied.
.
.

I've noticed for a long time that the first timer from System#Boot is called too briefly. It's not a current problem. After I log the debug port with Putty, I can now document it in a comprehensible way. The special situation immediately after a firmware upload can also play a role.

[IgorYbema]

Ok something for @CurlyMoo to look at. Not a breaker for v3.8

[McMagellan]

The behavior already exists in V3.2. Now I can document it.
I have reprogrammed my rule again now that the SetCurves command is available in Rules. Now that it's running stable (without frozen windows), I've given each rule a "print" command for clarity. That was a mistake. One of about four messages is not displayed in the console at all and, for reasons that are unclear, the uptime has been restarted three times (including at night) and then the ruleset is no longer loaded. I mean that the string management is not working correctly. Do not document the "print" command in the 3.8 rollout. I have reversed all print commands and am holding out hope that SetCurves will run smoothly. This command is the heart of my new Rule CoPilot V4. Next week things will get serious due to the forecast temperatures.

[CurlyMoo]

The timer is actual time independent. The only thing it does it do a count down. When a timer reaches a count down of zero it fires. The only thing that i can think of going wrong is that the timers are not fully cleared when parsing. So it fires after parsing the System#Boot instead of actually the first call of System#Boot.

[CurlyMoo]

So can you check if it fires 10 seconds after the System#Boot parsing?