Paged EEPROM writing proposal

[Enelar]

This merge is proposal of fighting annoying 1 update per hour limitation.

How it works. It reorganize memory layout of EEPROM.

Now it goes like this: | SIGNATURE | ACTIVE_PAGE_ID |

Where each page is: | WRITES_COUNT | PAGE_CONTENT |

Page is what you originally intent to store in EEPROM. But now each time WRITES_COUNT exceeds some threshold (I set it to 1000 writes), it copy current page content and move it to new page. So it wears EEPROM more evenly.
Also it stores WRITES_COUNT in memory, but writes it only on each 16 write, to further reduce stress on this cell.

Atmega has 1KB of EEPROM, so right now 59 pages fit in there. It has guarantee of 100.000 write/clear cycles per cell. So safe estimation for 10 years warranty is (59*100000/10/365/24) ~ 67 writes per hour.
I've updated TIME_ERRORS_PERMITTED and TIME_WRITE_PERMISSION to 60 writes per hour

[Enelar]

If you want to keep same weardown guarantee, then instead of allowing 67 writes per hour we can allow 59 writes - exact amount of new regions unlocked.

[Arnold-n]

Thanks for your PR, but I fear there is a misunderstanding here on the reason for the annoying limit on parameter writes. This limit protects the flash memory in the Daikin unit, not in the ATmega.

The ATmega EEPROM is only written if you switch mode (L0 to L1, L1 to L0 ) or if you change some of the other basic settings (V, C) which are supposed to be set only once. There is no protection against too many writes to the ATmega EEPROM, as such (ab)use was not anticipated - the system is supposed to remain in L1 mode. Thus no wear leveling was implemented.

The parameter storage in Daikin F-series indoor systems may (*) have been implemented in flash memory without any wear leveling. The problem is that we cannot resolve this issue ourselves, it is just a limitation from the Daikin system itself.

(*) In Daikin's Modbus Interface DIII design guide for the EKMBDXA7V1, a warning is included that "The number of control commands per indoor unit is limited to 7000 per year. If the BMS controls the units by using an automatic control program, please make sure it doesn’t exceed this limitation." The number of 7000x/year is likely based on 100.000x in an estimated life-time of 14 years. I remember a similar warning from another Daikin document which explicitly mentions flash wear as the reason for this limitation. The Modbus Interface DIII functions with many F-series systems as well as some simpler/older EKHBRD-A/EKEQ/EWAQ/EWYQ systems.

As Daikin does not warn about any limitation in write frequency for Altherma models in their LAN adapter documents, I can only hope that proper wear leveling has been implemented in the (newer) Altherma models - perhaps we can thus remove the parameter write limitation for certain models or make it an option to remove it for well-informed users.

I you are willing to risk flash wear, you can change the write frequency limits in the header file, but I would recommend to find another solution which limits the number of changes.

[Enelar]

Oh, that's very sad. My problem is - the unit is unable to keep temperature within desired contraints. More precise, it not able to keep temperature close to what is selected at the controller. I speculate it happens due to incorrectly placed thermometer (near air intake only). It's readings differs from my other zigbee thermometers in different rooms. (Its 23 degree in my living room, T0 temperature is 30, T1 temperature is 27).
I could just set desired temperature +4 degrees, but this deviation is not linear and not constant. This summer proved that as a fact. Only thing that helped me to survive heat and not get sick is fingerbot.

The only alternative solution I could think about is to add virtual thermometer device to the bus and somehow make unit make it's judgments based on this new sensor readings. Right now I need around 1 power cycle per hour to achieve this goal. (9 minutes cool down, 50 minutes waiting). I could just send "ambient temperature" instead of that. Hopefully it's not being written to the unit EEPROM. However I have no clue how to register such device on a bus.

[Enelar]

Controlling this virtual thermometer would make whole unit control much easier. I would just set it to "auto", and then set "current temperature" either colder than desired, hotter, or exactly as desired.

[Arnold-n]

I wonder if main controllers have the option to defer the room temperature measurement to a second, auxiliary, controller, to allow a virtual thermometer. But I doubt this is possible.

Two other approaches might be:
-observe as much of the protocol between main unit and FBQ* unit, and replace the main controller with the P1P2MQTT bridge, in which case we do need to program it as main controller; this may be tricky to get right, especially for the reboot procedure, or
-act as man-in-the-middle on the P1/P2 interface: two interfaces back-to-back, hoping the time delay may be acceptable (or work harder and ensure the delay is minimal), and modify the data to create a virtual thermometer.

[Enelar]

In my system I have these T2 T3 entities which have missing temperature reading.
Maybe there is a way to prefer readings from aux controller over what main controller reports. Or I could assume it would use average of these values or something. Yeah. Bummer. I guess I will have to accept quick failure of my AC.

[gmcmicken]

In my system I have these T2 T3 entities which have missing temperature reading.
Maybe there is a way to prefer readings from aux controller over what main controller reports. Or I could assume it would use average of these values or something. Yeah. Bummer. I guess I will have to accept quick failure of my AC.

I'm working on the same issue here with my F series unit. Actually I've built a controller to spoof the air intake thermistor, since I could not uncover any other way to send my own calculated temp. My field settings allow air intake, main controller, or both. And the algorithm to use both is wacky and unpredictable.