I’ve just bought a Shelly 2x 50 amp clamp kit, to use for client checks on high running cost etc.
Not set it up yet.
1 Like
I will be interested to know how that goes. This is the one that is on my list
From what I have been reading that is the best way to get SCOP.
solved the memory bug… but it is still a mystery 
But I now have it wired in and it is working 
hopefully that is the end of wifi drop outs.
I have made a pull request to the main ESPAltherma repo.
I am sure you don’t want to taking apart, but could you show some pictures of the cabling on the inside. I am still scared of the cabling side of things. I will certainly order one of these. Seems the perfect solution for outside.
The inside is typical, I am sorry I did not take photos.
On the inside of the M5 Tough there GPIO port (the black one) (see the docs for the Tough)
Which I have plugged in a 2m grove cable
which goes to one of these Grove-T Connector (5 Pack) | The Pi Hut
and on the other end is one of these Grove - 4-pin Female Jumper to Grove 4-pin Conversion Cables (5 Pack) | The Pi Hut
Which plugs into the X10A pins. The black wire is ground (connects to pin 5), red is VCC but you don’t need to connect that as it is powered over USB, white cable is TX (connects to pin 3), and yellow is RX (connects to pin 2).
You cannot really go that wrong with the cabling. If you get the TX and RX mixed up it wont break anything and you can just swap them over.
I need to get another M12 waterproof connector for the bottom where the wires are coming out so it is fully sealed. But as it is on the bottom it should be safe enough for now.
https posting from main ESPAltherma code in testing from M5StickCPlus2 without need for PI or HA…
Will share via github in due course.
Will also look at the tough version too, thanks for the ideas 
2 Likes
Hello All,
It was a nice day yesterday and I had some unexpected spare time, so I turned off the power and wired up the EDLA09D3V3. In the end I went for option 2 outside the conduit, primarily for ease of access to the M5StickC+1.1 if I need to flash it in the future. I ran 4 core alarm cable from the altherma via the egress point at the rear (which I circled previously in the thread) under existing cable ties for other HP cabling and through the garage wall into the garage (where the closest mesh satellite is).
The ping response time is still fairly variable:
Reply from 192.168.0.34: bytes=32 time=251ms TTL=255
Reply from 192.168.0.34: bytes=32 time=158ms TTL=255
Reply from 192.168.0.34: bytes=32 time=69ms TTL=255
Reply from 192.168.0.34: bytes=32 time=305ms TTL=255
Reply from 192.168.0.34: bytes=32 time=359ms TTL=255
Reply from 192.168.0.34: bytes=32 time=144ms TTL=255
Reply from 192.168.0.34: bytes=32 time=129ms TTL=255
Reply from 192.168.0.34: bytes=32 time=300ms TTL=255
Reply from 192.168.0.34: bytes=32 time=209ms TTL=255
Reply from 192.168.0.34: bytes=32 time=123ms TTL=255
Reply from 192.168.0.34: bytes=32 time=26ms TTL=255
Reply from 192.168.0.34: bytes=32 time=267ms TTL=255
Reply from 192.168.0.34: bytes=32 time=191ms TTL=255
Reply from 192.168.0.34: bytes=32 time=101ms TTL=255
Reply from 192.168.0.34: bytes=32 time=15ms TTL=255
Reply from 192.168.0.34: bytes=32 time=232ms TTL=255
Reply from 192.168.0.34: bytes=32 time=125ms TTL=255
Reply from 192.168.0.34: bytes=32 time=45ms TTL=255
Reply from 192.168.0.34: bytes=32 time=269ms TTL=255
Reply from 192.168.0.34: bytes=32 time=206ms TTL=255
Reply from 192.168.0.34: bytes=32 time=101ms TTL=255
Reply from 192.168.0.34: bytes=32 time=34ms TTL=255
However, I’m not getting dropped packets when the cover is back on and it’s connecting to my main network now rather than via a separate access point.
Crimping the make connectors was the hardest part for me, as I haven’t done this before. In hindsight it would have been quicker and easier to use another 4 short dupont m:m cables and put one end into a termination block or do the same with one end stripped as I see others have done.
I’ve noticed the sensor is listed as “sensor.none_althermasensors”. Any idea why it isn’t “sensor.althermasensors”? More specificially, how I can get it to that name?
Thanks for your help and advice.
Tim
It sounds like its trying to name it using the {device}_{entity} MQTT format from the discovery.
I would guess its a difference in later versions of HA than when mine was setup as mine is just sensor.althermasensors? I think you can just rename the friendly name and the entity_id on the entity properties page as it has a unique_id configured anyway?
Maybe related to PSA: MQTT Name changes in 2023.8 - Configuration - Home Assistant Community
I was playing with my M5 Tough yesterday. I don’t have a heat pump to test with yet, but I did test the Home Assistant side. What you saw is what I saw, none in the name. I was following the Speak To The Geek video on this. I did email him and he said I could just rename it.
Thank you Ben & Michael. I have renamed the entity. For some reason I thought it would be harder to resolve than that…perhaps the name would be recreated each time it was published.
1 Like
I have just opened my first pull request for ESPAltherma:
I hope the community goes easy on me! I don’t do coding very often (as a heat pump installer!)
Hi @Phil_E Looks like a relatively quiet reception over there…
One other thing is that ESPAltherma uses “ON”/“OFF” for, well, ON and OFF e.g. BSH (Booster Heater) is ON/OFF, rather than 1/0, as EmonCMS expects. I convert those in NodeRed, receiving the MQTT ON/OFF and rebroadcasting as 1/0. You won’t have that option, the ON/OFF show up as “null” in EmonCMS. It’s probably worth checking out the converter.h routines that set those values, and switching them under control of an #ifdef option to be 1/0.
In addition, I also synthesised separate MQTT messages for Space Heating 0/1 and DHW 0/1 from “3way valve(On:DHW_Off:Space)” i.e. take the ON=DHW, OFF=SpaceHeating, and convert to 0/1 for both. Not sure how necessary that was, but it does work to separate Power Input/Output between them.
Fyi I have had ESBE open for defrost but not during DHW. Not sure if it’s because I have a hydrosplit, it doesn’t do it all the time or even that often but I had to put some additional conditions for when DHW is on 
Thanks Ben and John, much appreciated as it’s hard to code up the handling of a message I can’t yet see. I don’t have a Daikin of my own, despite installing them for others. I’ve a few clients who are up for having one, but only when it’s working.
For on/off to 0/1 I can imagine how this can be fixed. I’ll take a look, and see if I can #ifdef that in, based on HTTPS being defined.
For the 3 way valve, are you saying that the default program gives one of 2 outcomes? (on:DHW or Off:Space). This would make sense as the wiring of the valve itself is a permanent live then a switched live that puts it in the DHW position, so ON being LIVE being DHW position retains the logic.
@meatballs I was under the impression that defrost could be done in either mode, is there something I should do differently here?
Erm not sure I have the best logic for it, as my main concern was stopping it tagging DHW periods in the middle of the day when it was defrosting. There’s a potential that this could tag a DHW defrost against climate stats:
espaltherma_dhw_on:
friendly_name: "Altherma DHW On"
value_template: "{{ states('sensor.espaltherma_esbe_valve') == 'ON' and states('sensor.espaltherma_defrost_operation') != 'ON' }}"
I could probably check against the I/U operation mode on mine as it reports Heating, DHW, Stop, but can also report Heating + DHW which clouds things. Not sure if I/U is available for monoblocks as mine is a hydrosplit with indoor unit.
Also spotted another defrost where its using the cylinder… I wonder if its a quirk and its not valid as the flow temp drops down to 13C and needs backup heaters to recover, but if it was going through cylinder coil (which was supposed to be 34C at the time) you’d think it would maintain temperature despite defrosting.
I might go with:
value_template: "{{ states('sensor.espaltherma_iuoperation') == 'DHW') or (states('sensor.espaltherma_iuoperation') == 'Heating + DHW') and states('sensor.espaltherma_esbe_valve') == 'ON'))}}"```Hey @Phil_E , no problem! Happy to help. The larger world appreciates what you’re doing! I have a friend with a planned Daikin install, who could well be using your version, just to avoid more hardware lying around, so respect.
If it helps, I could run it and get some message output if you’d like to see that. The project could really do with a testing framework, the best thing would be another ESP32 or equivalent that fired back whatever you told it over a serial link. Maybe that’s a project, it just has to catch the register requests and fire back a canned message, after all.
on/off → 1/0 - the converter.h code has some obvious “ON”/“OFF” translations, in fact I think they convert from, yes, 1 and 0! 
Yes, 3-way valve shows either ON => DHW, or OFF => Space. Since as far as I can see the EmonCMS HeatPump app takes separate variables for this, they have to be separate, with DHW = NOT Space and v.v. - see screenshot:
The Defrost flag works once converted to 0/1. I have to assume that the HP can have a defrost occur while doing DHW, in fact would be likely to since it involves moving a lot more heat than Space heating.
Thanks @John and @meatballs , been working on with it today. I’ve removed my original pull request and fork and made a new fork. I’ve re-formatted my work into a more sensible structure, preserving the original mqtt.h file for just mqtt activity and putting my https function call in its own https.h file, then the main.cpp has checks to see if it’s doing HTTPS or MQTT every time it is asked to do anything, so it can call the respective functions accordingly. I’ve mirrored the jsonbuff data as jsonbuffhttps so there is a new variable for clarity.
John, glad there is a customer in mind
I’d love to see some of the data as it comes out, even just a print of the jsonbuff variable on a live system as it’s been captured.
I’ll publish again in github soon, but for now, I agree, looking in there I see:
so there is conversion of cases to strings - Ben, this goes some way to showing the different responses you’re getting on mode…
Next step is to figure out which of the convert tables to modify for emoncms, and how, such that no strings end up as data…
Questions / confirmation of my understanding:
Emoncms can’t have any text in the data, only numbers?
Can the emoncms heatpump app DHW mode flag be whatever variable we chose to give it as long as it’s data is a 0 or a 1? (I think so, and when i;ts not 0 it gives the shading to the chart)
Why does emoncms app want the heatpump_ch data? Is it necessary, if we know when it’s doing DHW then surely the rest is heating?
I don’t see the defrost data in the emoncms app setup - that right?
As for Ben’s work/question/suggestion on how to know for sure in the best way when the HP is actually doing DHW (not defrosting), for this application here there is no PI/HA can this be processed in emoncms inputs on arrival before it’s fed to the emoncms heatpump app?
Thanks again
Hi @Phil_E
converter.h has table 300 & 200, which just look at either a bit or an 8bit value to set ON or OFF. Frankly, fixing all the other values which are strings of greater complexity seems like overkill at this point, since they generally aren’t data you’re interested in.
- I believe that is the case - @TrystanLea can confirm/deny that; I see that there are conditionals on NULL, but of course, every tex data point is a NULL, so that doesn’t help!
- Yes, you just point to the variable/feed from the MyHeatpump config in emoncms.org; that’s true for all the data feeds
- Search me! Again, @TrystanLea can comment, I guess it’s possible the HP could be doing cooling? Or maybe neither if on standby?
- Curiously, yes, IMHO it would be a useful addition. You can graph it using the Graph screen, which is what I do. One more time, @TrystanLea might want to comment
- Depends on what the processing is - there are lots of functions available in the Input processing. There are conditionals, so you could check if = 0, then skip next processing function, for example, then that would make a Feed data point of the appropriate value
Thanks for your efforts, again, appreciated. Maybe we should also all contribute to raomin’s coffee fund…
Thanks @John. Agreed on the coffee front, It’s quite a bit of code I’ve just sent his way!
I just found the explanation in a file called “Daikin I Protocol.md” under doc.
converters.h is using convid to decide what to do in the switch code.
Interestingly in the EDLA monobloc .h file there is no ‘200’.
lots of 30X’s though.
In converters.h, cases 300, 301, 302, 303, 304, 305, 306 and 307 all call the convertTable300() function.
As for an approach, I’d like to maintain the integrity of the original program, with as little disruption as possible, but I also didn’t want to have to duplicate lots of the code to create the ability to have 2 different data sets being created simultaneously (the ON/OFF set and the 0/1 set). This would only be needed to send MQTT messages and HTTPS messages to 2 different places, in 2 different formats, if MQTT couldn’t be set up to cope with 0’s and 1’s.
So in converters.h I added:
and modified the 200 and 300 functions to contain:
and
Pull request now re-posted on github:
1 Like
@Phil_E Whizzo! The table-driven conversion makes that change relatively easy, fortunately.
Apologies if the following is not clear or misses something - just trying to assist! The main thing would be to compile it and run it with an actual Daikin, I guess 
Summarising:
- Defining BOOLNUM in converter.h determines if 0/1 or OFF/ON used, independently of HTTP(S) or MQTT data transmission; both MQTT and HTTPS will send whatever is set here for boolean values
- Defining HTTPS in setup.h causes inclusion of https.h and invokes sending of HTTPS buffer, which includes the ESP32/M5StickC/+2 operational values; it also subs some invocations of mqttSerial with Serial
- Defining MQTT in setup.h causes sending of MQTT buffer
So using EmonCMS only with NO MQTT broker requires at least
- Defining BOOLNUM
- Defining HTTPS
- Not defining MQTT
- Not defining ONEVAL_ONETOPIC (which is currently needed for EmonCMS via MQTT) - that does a sneaky publish in updatevalues(), one per data item/topic
mqttserial.h checks the MQTT client and only uses if it’s valid/connected, which is why it works in setup() before the client is set up by reconnectMqtt().
I wonder if adding an EMONCMS define that sorts all that out might be a plan. I really hate all this optional compilation stuff, never used it in real life, possibly because I’ve never had the problem of memory shortage!