-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Let's discuss some things here... so we are closer to the source :-) #1
Comments
Hello, Power - sensor.heatpump_power "SG-ready" 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. 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. 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. Calculated Sensors Where you would put that coding depends on how your configuration.yml file is set up.
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. Conclusion
|
SG ready A in the heatpump is used if the energy supplier wants to turn off your heatpump from remote I believe. About wiring the Shelly, This is by far not a recommendation to do this… So doing at your own risk! 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. |
Actually I think my firmware of the heatpump is a lot older than yours. When I open the Website it looks nothing like this. 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… |
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... |
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. |
@marq24 I uploaded a communications manual for Waterkotte heatpumps to my (waterkotte) repo. Maybe it is possible to use it for your integration. 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). I would of course really look forward if we could have a state which shows the exact error message based on these registervalues. :) |
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 |
@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. |
so basically display the I52 & I53 each as "joined" string value (based on the bits) |
@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 🤭 ) |
there is no need to create an issue... I'll take care of that (in the next couple of days) |
Awesome. See also the PDF with all registers that were available 2012 in the files in this repo. |
I checked the PDF already and did not found any TAGs that are not available yet in the code... Did I miss some? |
I am a bit in a dilemma... based on the pdf from 2012... 1: "F100: Motorschutzschalter 1", but in the current web-interface there are plenty of additional/new values "F111: Verflüssigungstemperatur zu niedrig", 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. |
@marq24 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. |
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)
|
... 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:
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)... |
Yes, I agree with you. And sorry that I did not respond earlier, but I had other things in my mind the last weeks. |
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" |
@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. does this happen for you? |
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 |
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). |
finally I have found some value able information - and just created a new release: |
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
and I am done - right?
The text was updated successfully, but these errors were encountered: