flautze / home_assistant_waterkotte

1 stars 0 forks source link

Let's discuss some things here... so we are closer to the source :-) #1

Open marq24 opened 10 months ago

marq24 commented 10 months ago

additional Sensors

In your readme you mentioned: There are several entities that are not... I have found these two - so "several" = 2 right?

power - sensor.heatpump_power

For the power-consumption: I assume you have some sort of additional meter in front of your waterkotte, so that you don't have to use sensor.wkh_power_electric [and of course this sensor of the integration is providing data in kW]

"SG-Ready" - switch.shellyplus1_441793cd71c8_switch_0

This might be very interesting for me (and probably other) - I assume you have build/attached to your waterkotte a shelly switch - and when you trigger this shelly the waterkotter received the required SG-Ready signal?

I would like to see details about this - specially the wiring of the shelly and the waterkotte "main-bus" - IMHO there are two SG-ready lines - my understanding is, that there are two independent channels... I have a SG-Ready component also in my PV-unit - but this is not connected to the waterkotte yet - and if I could simply trigger the SG-Ready stuff manually (via HA) by triggering a shelly I would also like to have this [I have already I shelly pro 4pm in my garage - using it mainly for controlling the garden-water-pump and the pool]...

calculated Sensors...

You provide all of the additional required (calculatable) sensors in the https://github.com/flautze/home_assistant_waterkotte/blob/e0f7c37dbfc239de030cdd24ee47d32839765111/templates.yml file - I guess (i never did that) it's possible in HA to separate template sensors in a additional file... Is it then required to link this additional file in the main configuration.yaml - or is this only the case, if I am using a different filename? [in my local setup I always include all additional template/rest sensors in the main configuration.yaml OR I have a single separate file per "feature" (linked in the main configuration) that includes all the additional sensors, helpers and automations]

conclution

  1. I need at least one additional sensor (the shelly) - or I remove that from the card configuration
  2. Power can be relaced with sensor.wkh_power_electric ?
  3. inserting the content of the templates.yaml in the appropriate section of my configuration.yaml
  4. install the HACS CardMod (had it already)
  5. copy the graphics to the specified folder
  6. remove all navigation path related stuff
  7. past then this modified content of waterkotte.yaml as new card

and I am done - right?

flautze commented 10 months ago

Hello, The sensors are listed here as well: https://github.com/flautze/home_assistant_waterkotte#changes-required

Power - sensor.heatpump_power So yes, these 2 sensors are not available from the integration. Shelly_power is coming from a Shelly 3EM which I use to measure the power consumption and energy of the heatpump (it replaced the additional Energy Counter from the Energy Company). I trust these values more than I trust the electric power from Waterkotte ;) You can use any sensor instead or just remove that line.

"SG-ready" When I had the last service of my heatpump I discussed with the technician how to do it. Anyhow, I just removed the sidepanel of the heatpump, then pulled out the board with all the electrical components (it was secured with 1 or 2 screws) image

Since I know which were the 230V and neutral I connected the power of the Shelly 1 Plus to that, and then the switching output to X2 34/gnd - according to the manual of my heatpump.

image

Please note, that you should have good WIFI in that location, since Shelly uses WIFI to ciommunicate. My Access point is approx. 2-3 meters away so I have a good signal even with the Shelly installed inside the heatpump. You could also probably route the cable out in the back so the Shelly sits outside the heatpump, but I did not want to expose the 230VAC outside the heatpump.

For switching the shelly I created an automation in HA, which very simply looks at the current solar yield as well as the forecast and then switches accordingly. If you do not need that component, then simply leave out or replace with something else.

Calculated Sensors usually there is several ways to use own sensors in Homeassistant. I recommend the addon Visual Studi Code Server to edit these files (or alternative File Editor addon).

Where you would put that coding depends on how your configuration.yml file is set up. 1) if you have all your custom config in the configuration.yml then simply copy/paste the templates.yml code to your configuration.yml 2) sometimes there is an include for all templates in the configuration.yaml. It looks like this template: !include templates.yaml If you have that you need to put the coding into the templates.yaml.

Please note: I have changed the coding in templates.yaml in my repo to match the formatting requirements of the templates.yaml. Also I have created another file. configuration.yaml, so if you use way 1) you have to copy/paste the coding from that.

So, I have created a new file configuration.yaml and changed the templates.yaml. If you do your manual sensors via configuration.yaml then use the code from that respective file and copy/past. Please note however you should only have each tag once, so if you already have a template: section, remove that line. If this is your first custom sensors, simply copy/paste. If you want to define the templates in the templates.yaml, add the "include" I described above, and then copy/past the coding from templates.yaml to your templates.yaml.

Conclusion

  1. Yes
  2. Sure, it can be whatever. Or you can remove it.
  3. As described above, use the coding of configuration.yaml
  4. yes
  5. The folder of the graphics is identical to the folder which you should see on your Home Assistant installation. In order to do that you might want to set up Samba-service to access these folders via Windows ( go to settings -> addons and look for Samba Share in the Store)
  6. you do not need to remove it. If you click on the icons it will simply not navigate if the page is not available. However you can also remove it.
  7. Yes, create a new card - any type, and switch to YAML-mode, then copy/paste.
marq24 commented 10 months ago

SG-Ready

So you "ignored" SG-Ready A - and simply/just switch SG-Ready B at your Watterkotte (and simply keep the bridge between GRD & Pin 3 - right?

And since I am not a Elektro-Expert - can you also explain how you connected the shelly? image

Ok here is what I understood so far - L & N need to be wired to the V230 (that I need to find somewhere in the Waterkotte - I guess I can manage that)... I assume SW and 12V can be ignored - and I/1 and 0/0 goes to 4 and the the GRD (and IMHO which goes to what does not matter - can be exchanged with each other)... at least that is my current understanding - am I right?

So the Shelly is more or less just a switch - connect/disconnect the I and 0 - when on/enabled, power can go from I to 0 - when off/disabled, the I and 0 are disconnected from each other - the Shelly does not send any power from L/N through this I and 0 connectors - right?

My SG-Ready Interface from my PV (Senec) have 4 cabled that I can connect... Channel I and Channel II - so I always thought, that C1 have to go to SG-Ready A and the C2 must go to SG Ready B... But as soon as I have removed the bridge of the SG-Ready A the Heatpump only starts with an error code - or better does not really start up at all...

Of course you can't tell me, the meaning of Channel I and Channel II of my Senec Device... But most important for me is, that you just connected SG Ready B... (and kept the bridge)...

So I might install a) a shelly as well - AND also connect Channel1 of the Senec - actually should not be important, which of the two are closing the electrical curcuit between PIN 4 and GRD

flautze commented 10 months ago

SG ready A in the heatpump is used if the energy supplier wants to turn off your heatpump from remote I believe. So that is why it has to be bridged, because if turned off (no signal) then the heatpump would be locked.

About wiring the Shelly, L cable should be black(230V) , N (Neutral or 0V)should be blue, so blue goes to N, black to L. However since it is alternating current I think it would also work the other way around.

This is by far not a recommendation to do this… So doing at your own risk! 12V is used for supply voltage 12VDC instead of 230VAC. SW, you can connect an external switch (light switch for example) to switch the output I/O by pressing that button - as to my understanding.

Between O and I there is a switch, and yes O and I go to X2/4 and X2/GNDof4 (if your heatpump uses the same terminals).

So if you close the switch there is a loop and the heatpump will know there is enough solar.

if your Senec provides also SGready, you need to find out which wires are used to signal that, and if the contacts are potential free. Then you would not need the Shelly. In case the cable is long enough and both contacts of your Senec provide that info (and are potential free) you should prefer that solution probably. Then you don’t have to mess with the 230VAC in the heatpump.

marq24 commented 7 months ago

It took me a while to do some wiring at the heatpump - but over xmas I did it - now I have a question... Is there a way to see, if the SG-Ready Switch is turned ON?

I am asking - cause I notice a new Icon when accessing the regular webportal of the heatpump: image

zoomed: image

is this sg-ready icon present, when the SG-Ready switch (in your case the Shelly) is ON - and is there no icon, if your Shelly is OFF?? Would be cool to know... If this is really the case then I might have a surprise for us all...

flautze commented 7 months ago

Actually I think my firmware of the heatpump is a lot older than yours. When I open the Website it looks nothing like this. On the display I also have no possibility to see if the SG is on or not. I track that in Homeassistant.

what I noticed though is, that when my heatpump is making water and SG ready is on, when reaching the normal water demand (44degree) it turns off. Just immediately after turning off, it turns on again with 10 degree higher water demand temperature (from SGready).

Maybe because of the old firmware…

marq24 commented 7 months ago

mmmh - ok - thanks for your fast reaction [just as info - a possible attached screenshot did not make it here to github] - but I would assume there is not much "visual" that could be catched from that...

I have found yesterday evening some DIGITAL INPUT & OUTPUT Tags of my Waterkotte and I wanted to know, if this SGREADY INPUT D795 might be already enough to turn SGReady ON or OFF? [of if this is a general switch which needs to be enabled in order that SG-Ready interface can be used in general - OR if this is an alternative way of switching the SG-Ready signal... But since I do not know the default behaviour (what should happen when SG-Ready Signal is ON from the PV), I can not judge if this newly discovered D795 Tag can replace your Shelly...

flautze commented 7 months ago

As far as I know the SGready are only readable not writeable. Therefore you cannot switch these digitally but need hard wires. At least for my heatpump. Somewhere I have the operators manual for my heatpump and I remember that there should be some Modbus information in there… If you are interested I can look for it.. My heatpump is from 2013 though.

flautze commented 7 months ago

@marq24 I uploaded a communications manual for Waterkotte heatpumps to my (waterkotte) repo. Maybe it is possible to use it for your integration. I cross-checked some references and it seems to be the same (for example A32 on page 9 refers to setpoint of the heating setpoint. So that seems okay.

What I am aiming towards is to evaluate the error/fault-messages and have the integration show the distinct error description instead of simply a number. I assume currently wkh_state_service is used for that? or binary_sensor.wkh_state_alarm )I was not able to find out if that is already implemented.

See page 4/5 of the PDF which you can find in my repo ( or here as screenshot). Maybe you have use for it image image

I would of course really look forward if we could have a state which shows the exact error message based on these registervalues. :) If you need assistance please let me know.

marq24 commented 7 months ago

might be my day at work was just "too long"... but I have difficulties to pick up your train of thought - in the current implementation of "my" integration I52 and I53 are not present yet [or at least the bit fields are no present] - with your information (pdf) I can add them now...

Some of the current implemented/available state fields are coming from I51 -> e.g. bit 6 "Alarmausgang" - other like the "State Service" is coming from I135

flautze commented 7 months ago

@marq24 thats okay and probably my train of thought sometimes is too confusion.

My intention was to have the state_alarm replaced by another sensor that shows the state or error/information message in plain text.

Alternatively the sensor could show the value of the bits - which then can be transformed to the respective plain text message. For example using the pdf/manual and Jinja template. Of course the first solution would be better.

marq24 commented 7 months ago

so basically display the I52 & I53 each as "joined" string value (based on the bits)

flautze commented 7 months ago

@marq24 Yes, basically that was the idea. Then it would be possible to see what error is showing in Home Assistant (apart from that my heatpump has not produced one single error in 10 years after we moved in 🤭 ) Should I open an issue in the repo?

marq24 commented 7 months ago

there is no need to create an issue... I'll take care of that (in the next couple of days)

flautze commented 7 months ago

Awesome. See also the PDF with all registers that were available 2012 in the files in this repo.

https://github.com/flautze/home_assistant_waterkotte/blob/main/Kommunikationsdaten%20ModBus%20RS485%20Waterkotte%20W%C3%A4rmepumpe.pdf

marq24 commented 7 months ago

I checked the PDF already and did not found any TAGs that are not available yet in the code... Did I miss some?

marq24 commented 7 months ago

I am a bit in a dilemma...

based on the pdf from 2012...

1: "F100: Motorschutzschalter 1", 2: "F101: Motorschutzschalter 2", 3: "F102: Phasenfolgeüberwachung", 4: "F103: Störung Wärmequelle", 5: "F110: HD-Pressostat", 6: "F120: ND-Pressostat", 7: "F122: Temperaturüberwachung Verdampfer", 8: "F123: Nasslauf",

but in the current web-interface there are plenty of additional/new values

"F111: Verflüssigungstemperatur zu niedrig", "F121: Drucküberwachung Verdampfer", "F130: Ausfall 4-Wege Ventil", "F200: Steuergerät Kommunikationsüberwachung Ausfall", "F201: Das Gerät pCOe oder EVD ist nicht vorhanden oder funktioniert nicht richtig", "F301: Ventilmotorfehler", "F600: Störung Außeneinheit"

the question is, how this will fit into the 2012 list - in total that will be 15 values (so enough space for additional new values)... but on the web-gui the order is not matching the order of the 2012 pdf... :-/ [in the web the codes are ordered by the F-code]... so between 5 and 6 there would be F111.

flautze commented 7 months ago

@marq24 Hm that is a good question. It does not make sense to only go for the 2012 values, as this would be one specific heatpump only.

Are these coming from the same register, only different bits? Or how do you get these values?

Or a possibility maybe to use a sensor for the error, so for example if the error is F301 the sensor will get that value. At least the error itself would then be shown in HA. And it is not bound to only a certain pump. Translation could be done locally - if required - via mapping/ jinja.

marq24 commented 7 months ago

the I52 document in total 15 bit's - this is matching the total number of available error codes from the DICT.js of the waterkotte web-frontend - so the number of flags can be matched...

But the order of the different error codes in the current web-frontend differs from the order of error codes from the PDF... So I am clueless how to add the "new" codes...

Normally I would assume (as software developer), that all new flags will be appended simply at the end of the 2012 list - no matter of the actual error code (sort order)... But the order in the DICT.js is simple following the order of the error codes. I was not able (yet) to find the place (js) where the error codes will be actually used in the frontend.

you might be smarter then me - here is the lng identifiers... I am really not interested in the translations of the strings - for the HA integration I would have already a solution for that - it's the bit-assignment (order) I want to know (since if I do mess this up, this will result in the FALSE error messages)

lngD1 = ["F100: Motorschutzschalter 1", "F100: Motor protection switch 1", "F100: Protection moteur 1"],
lngD2 = ["F101: Motorschutzschalter 2", "F101: Motor protection awitch 2", "F101: Protection moteur 2"],
lngD3 = ["F102: Phasenfolge\xfcberwachung", "F102: Phase sequence monitoring", "F102: Erreur de phases"],
lngD4 = ["F103: Prim\xe4rseite", "F103: ", "F103: "],
lngD5 = ["F110: HD-Pressostat", "F110: HP-Pressostat", "F110: Pressostat HP"],
lngD6 = ["F111: Verfl\xfcssigungstemperatur zu niedrig", "F111: Condensing temperature too low", "F111: Temp\xe9rature de condensation trop basse"],
lngD7 = ["F120: ND-Pressostat", "F120: LP-Pressostat", "F120: Pressostat BP"],
lngD8 = ["F121: Druck\xfcberwachung Verdampfer", "F121: Pressure monitoring evaporator", "F121: Contr\xf4le de pression \xe9vaporateur"],
lngD9 = ["F122: Temperatur\xfcberwachung Verdampfer", "F122: Temperature monitoring evaporator", "F122: Contr\xf4le de la temp\xe9rature \xe9vaporation"],
lngD10 = ["F123: Nasslauf", "F123: Wet run", "F123: Gaz liquide"],
lngD11 = ["F130: Ausfall 4-Wege Ventil", "F130: Failure 4-way valve", "F130: Panne vanne 4-voies"],
lngD12 = ["F200: Steuerger\xe4t Kommunikations\xfcberwachung Ausfall", "F200: Failure control unit communication monitoring", "F200: Panne contr\xf4le de communication de unit\xe9 de contr\xf4le"],
lngD13 = ["F201: Das Ger\xe4t pCOe oder EVD ist nicht vorhanden oder funktioniert nicht richtig", "F201: Device pCOe or EVD is not available or does not function properly", "F201: Le pCOe ou le EVD est absent ou ne fonctionne pas"],
lngD14 = ["F301: Ventilmotorfehler", "F301: Valve motor error", "F301: Erreur moteur de vanne"],
lngD15 = ["F600: St\xf6rung Au\xdfeneinheit", "F600: Failure outdoor unit", "F600: Panne unit\xe9 ext\xe9rieure\t"],
flautze commented 6 months ago

Hm... I dont think I competely understand. SO the integration is based on the frontend/js modules supplied by it, correct? And you are having issues to read the error codes from the frontend to bring these to HA.

Since my heatpump is pretty old, I dont think I have the current webinterface... mine looks like this (and does not supply all data). Probably the old interface (Easy-con... new is EcoTouch I believe?) image

image

marq24 commented 6 months ago

... yesterday evening I made a decision... I assume, that Waterkotte developers would not be totally foolish (and change between different models the meaning of bitfields - and assuming that new values have been added at the end of the existing list...

So I will implement this dict:

            0: "F100: Motorschutzschalter 1",
            1: "F101: Motorschutzschalter 2",
            2: "F102: Phasenfolgeüberwachung",
            3: "F103: Störung Wärmequelle",
            4: "F110: HD-Pressostat",
            5: "F120: ND-Pressostat",
            6: "F121: Drucküberwachung Verdampfer",
            7: "F122: Temperaturüberwachung Verdampfer",
            8: "F123: Nasslauf",
            9: "F111: Verflüssigungstemperatur zu niedrig",
            10: "F130: Ausfall 4-Wege Ventil",
            11: "F200: Steuergerät Kommunikationsüberwachung Ausfall",
            12: "F201: Das Gerät pCOe oder EVD ist nicht vorhanden oder funktioniert nicht richtig",
            13: "F301: Ventilmotorfehler",
            14: "F600: Störung Außeneinheit",
            15: "BIT15: UNBEKANNT"

at the end of the day I have no clue, when 'F111' have been introduced - so it might be, that every error greater then bit 8 will not be correct...

Fun fact, my Waterkotte return for I52 frequently the int '16384' -> so bit14 ist TRUE... now I just have to guess, what could it be?! - The original Webinterface of the Waterkotte does not show anything (at the same time)...

flautze commented 6 months ago

Yes, I agree with you. And sorry that I did not respond earlier, but I had other things in my mind the last weeks. let me know if I can help somehow or test.

marq24 commented 6 months ago

JFYI - actually I decided (in last minute) for an alternative solution - I only show/evaluate the bits 0-8 ... so we are for sure safe... since bit14 "Störung Außeneinheit" can't be valid for my System - I don't have a "external Unit"

flautze commented 6 months ago

@marq24 ate you using the SG ready to increase Warmwater temperature?

Strangely the behaviour is not as expected for my heatpump. The water demand temperature should rise by 10K when SG ready is active. However it only does so when my „normal“ water cycle is complete. Result is. Heatpump is making water up to 46c, then water (and compressor) is turning off. Then once not running immediately the demand temperature is rising to 55c. heatpump will turn on again. Result is I have 2 compressor starts, although the water could just be made within one start…

does this happen for you?

marq24 commented 6 months ago

I still did not manage to solve my SG-Ready setup... I have to admit, that with all options in HA I don't have much motivation to try to solve it... -> I can increase all values [temperatures] when there is a PV plus...

So to answer your question: "I don't know' - and probably I will never get to this point :-/ sorry

flautze commented 6 months ago

That is probably what I will do now since the switching between PV Ready on/off is too inconsistent. ( between approx 8am and 3pm activation of SG ready does not have an effect on the water demand temperature - I have all schedules to 0-24 and nothing else). Therefore I will probably remove the Shelly and do the change to temperature setpoint within Homeassistant as well.

marq24 commented 4 months ago

finally I have found some value able information - and just created a new release: https://github.com/marq24/ha-waterkotte/releases/tag/2024.4.2