kodebach / hacs-idm-heatpump

HACS integration for IDM heat pumps
MIT License
20 stars 1 forks source link

Add further "save to write" modbus registers to integration #93

Open AndyNew2 opened 3 months ago

AndyNew2 commented 3 months ago

According GLT monitor, there are further registers we can use: Save to write means, the values should not be used for flash memory write and therefore there is no limit in writing cycles.

According this we could add 1713 for trigger a warmwarter cycle. It is a char needs written. Write first 1 to it to initiate the cycle, wait 1 minute to give the iDM logic time to read the trigger and reset the modbus address 1713 to 0 again. This is necessary, because otherwise we would constantly trigger warmwater cycles. This is OK as long the cycle is ongoing, but anyoing, when it is supposed to be finished.

Similar support may be added for the register 1711 and 1712, but I do not know yet, how they can be used or "misused". They are intended to work only with external Puffers, but at least the warmwater value seems to work also for the integrated buffer.

Furthermore I like to request the write support for Zone Modul, for each room for the value Betriebart. E.g. Register 2007 is supposed to control the operation mode for room 1 on Zonemodule 1. Next one would be 2014 for the next room. This would allow to configure, if the room currently should work in "Automatik", "Eco", Komfort" or even 0ff. Since the automatic control from iDM Software is more than bad, this would give a lot better control of the heatpump by:

  1. Allowing to control rooms not just on hour base, but on minutes or seconds.
  2. By giving a better timing control, a reasonable overlap from one to other rooms can be controlled. This would guarantee, the heatpump not switches off and restarts for the next hour, but continous work from room 1 to room 2 and so on. I actully have a use case for this.
  3. Switch off the heatpump by setting all rooms to off or at least Eco, when the iDM Software contiously starts and stops the heatpump in case the heating power is too high, which occurs quite often.

According the iDM Documentation all Zone-Modules registers have no write cycle limitation as other registers have. This seems surprisingly but may be true, since that data is not stored? Worth to try. To complete the support we could add also the "Solltemp" for each room, that would give even more control.

kodebach commented 3 months ago

AFAICT 1710/1711/1712 are all only useful, if you want to control the heat pump operation entirely via Modbus instead of relying on the automation IDM provides. Basically you'd treat the heat pump more like a dumb heater (like natural gas powered or electric one) and just tell it when to run.

However, if you want to use the heat pump this way, I don't think using this operation would be the best way to do it. Instead you should probably raw Modbus. Because in such a scenario you either (1) replaced an old dumb heater with the heat pump and want to keep the same control logic as before or (2) want to exercise some very specific controls to get better results than the IDM automation. In either case, I think this is advanced enough that I don't see it as a use case for the integration.

1713 could be integrated and exposed to Home Assistant as a button. However, you can also achieve this by setting up the modbus integration (see https://github.com/kodebach/hacs-idm-heatpump/discussions/75#discussioncomment-8135833) and using a template button with the modbus.write_register service as the action. I added it to the list in #50.

2007 and the other zone module registers actually seem the most useful to support from my POV. I added them to #50. However, I'm not certain when I will find time to work on this. In the mean time, once again, you could use the modbus integration in parallel to this integration. AFAIK there should not be any conflict, especially, if you only use the modbus integration for the modbus.write_register service. (Note: reading with both this integration and the modbus one, may result in differing values, since the reads will happen at different times).

You are of course also welcome to work on the code your self and submit a PR.

According the iDM Documentation all Zone-Modules registers have no write cycle limitation as other registers have. This seems surprisingly but may be true, since that data is not stored?

I assume the zone modules store the values themselves and the Navigator just reads them from there into RAM. So if we write from Home Assistant, we just replace in RAM what was read from the zone module.

AndyNew2 commented 3 months ago

I will try to implement a few myself. I tried 1712 on off. That could be useful to control photovoltaik overproduction used by warming hot water. By sending 1712 a 1 the heatpump immediately goes to hotwater mode, until stopped again by sending 1712 a 0. It will not stop according hot water generation settings. So that could be used to overheat the hot-water, when enough sunpower is there. I tried the HA modbus implementation and all worked perfectly. Since the idm heat-water logic is full of mistakes, I will disable the idm logik and code my one one in HA. If these registers will be added to the write control of this integration I will use it. And yes, I will try to understand your code and try a folk, however I am slow on this, too many other projects...

AndyNew2 commented 3 months ago

A bad news, got now finally input from IDM. The control registers on the Zonemodules are stored as well in a flash memory. So all writeable registers suffers the same limitation as the registers described by the heatpump itself. IDM will correct the modbus description. However they mentioned a casual writing by 4 - 8 times a day to a few of the regisers on the Zonemodule should not hurt. I am not so sure about that message, but tried to challange and see if the same applies to the heatpump registers itself.

If we could write 4 - 8 times registers per day to heatpump values, I would use on - off logic to overcome this uncontrolled heatpump starts.

kodebach commented 3 months ago

However they mentioned a casual writing by 4 - 8 times a day to a few of the regisers on the Zonemodule should not hurt.

Approx. 10 writes per day for 10 year is approx. 35,000 total writes. Considering the Modbus docs say 300,000 writes max, I would hope that this is fine. AFAICT the warning is mostly there so you don't hook up some "smart" home controller that writes values at a fixed interval of e.g. 1 minute regardless of whether anything has changed.

Generally, I would say as long as all your writes are (a) (indirectly) triggered by an action performed by a human or (b) happen at a rate at which human would also trigger such actions, you should be fine. After all the changes could have been made in the IDM interface directly and AFAIK IDM doesn't show any kind of warning there.

AndyNew2 commented 3 months ago

Just checked again the documentation. It states max. 300.000 writes. And it states it is a direct EEPROM Write. That combination could lead to issues earlier. The key is, if they have really the old sceme, writing to 1:1 adress space like in the very old days or having a operating system, saving parameters in files. That file writes are distributed over the whole EEPROM. That would mean a write to the same register would end in different EEPROM spaces. The algorithm is called wear leveling. I really assume, since they support modern WebGUI and TCP/IP requests they do no longer have this 1:1 assignment and the documentation is wrong in that state as well.

I asked already but didn't got an answer. I actually would assume, it is more safe to write to IDM control registers rather than ZoneModule registers. I would be really surprised if they still use a 1:1 flash registers for their storage (which could be possible), but why should they do so? Nobody else in the world does this anymore. On the Zonemodules, I would not expect an OS. So this memory is a lot more likely to have the old days 1:1 assignment to flash memory cells. These cells may die even after 10000 writes, which would mean with the calculation before about 3 years. That would not be great.

Grizzler89 commented 1 month ago

The documentation clearly mentions a maximum of 300,000 write operations per register. This is a normal value for EEPROMs. There is no reason to discuss how they achieve this value. Leveling or not. In the end, the documentation says 300,000 writes per register. And that is the amount we should expect.

AFAICT the warning is mostly there so you don't hook up some "smart" home controller that writes values at a fixed interval of e.g. 1 minute regardless of whether anything has changed.

The documentation also states that unchanged values are not saved to the EEPROM.

Generally, I would say as long as all your writes are (a) (indirectly) triggered by an action performed by a human or (b) happen at a rate at which human would also trigger such actions, you should be fine. After all the changes could have been made in the IDM interface directly and AFAIK IDM doesn't show any kind of warning there.

Exactly.

AndyNew2 commented 1 month ago

Sure no problem. Anyway everybody integrates it with it's own risk. In case the device gets broken it will be difficult for IDM to proof a modbus write destroyed the memory. The only point I want to make aware. The documentation is proofed to be wrong on the Zonemodules. I would not put my hand in fire for this 300000 write cycles. My suspect is, this is just used from some other outdated specs, but no proof for this either.

As most people stated here, as long there are only a few writes a day it should be fine. In my case, I can choose to either write to Zonemodule memory or main controller memory. My suspect is, the main controller memory should be able to handle a lot more than 300000 write cycles (due to wear leveling all operating systems supports). And a lot more compared to the Zonemodules, where I suspect no OS saves the memory. Therefore I will choose to write to the main controller instead of the Zonemodules whenever possible. And this is against the documentation, so I would not put tooo much focus on this 300000 write cycles documented there....