I'd be willing to collaborate on the software side.

 

Thanks, I'm more that happy to let you know what I've got so far. The EVSE module is controlled using Modbus over RS485. This is a pretty simple protocol, using a bunch of registers that can either be read from, or in the case of a few of them, written to. The Chinese documentation is pretty thin, as well as being both incomplete and containing a bunch of inaccuracies. So far I've been working through the registers one by one, trying to pin down exactly what each does.

The full register list is here (still a work in progress as there are anomalies in the datasheet):

Register Address​	Description​	Read/Write​	Data Type​	Default​
86​	Overvoltage protection value (0.01V)	Read & Write​	16 bit integer​	26500​
87​	Under-voltage protection (0.01V)	Read & Write​	16 bit integer​	16500​
88​	Overcurrent protection value (XX%)	Read & Write​	16 bit integer​	120​
89​	Remote start and stop (0 invalid, 1 start, 2 stop)	Read & Write​	16 bit integer​	0​
90​	1# Meter A-phase voltage address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
91​	1# Meter B-phase voltage address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
92​	1# Meter C-phase voltage address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
93​	1# total current address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
94​	1# total power address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
95​	1# Total KWH address number (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
96​	2# DLB current address of the meter (65535 is an invalid address)	Read & Write​	16 bit integer​	65535​
97 - 99​	Spare	Read & Write​	16 bit integer​	0​
100​	Device Address Number	Read & Write​	16 bit integer​	255​
101​	DLB maximum starting current	Read & Write​	16 bit integer​	3500​
102​	DLB maximum current (100.00A)	Read & Write​	16 bit integer​	4500​
103​	Reference current: DLB/current transformation ratio (100.00A) . 100/5 CT = 10000, 150/5 CT = 15000, etc	Read & Write​	16 bit integer​	10000​
104​	Reference current calibration value input	Read & Write​	16 bit integer​	1270​
105​	Charging pile current transformation ratio 50-200A	Read & Write​	16 bit integer​	​
106​	Charging pile current value correction 0-100.0A	Read & Write​	16 bit integer​	​
107​	Charging pile voltage value correction 0-500.0V	Read & Write​	16 bit integer​	​
108​	Charging pile power value correction 0-22000W	Read & Write​	16 bit integer​	​
109​	Output PWM write funct. 6 to this register to set duty cycle% x 100. i.e. 16A = 26.67% = 2667 = 0A6B	Read & Write​	16 bit integer​	9000​
110​	RCMU function selection 0 disabled 1 enabled, other values are selected by DIP switch	Read & Write​	16 bit integer​	3​
111​	RFID function selection 0 disabled 1 enabled, other values are selected by DIP switch	Read & Write​	16 bit integer​	3​
112​	Lock function selection 0 disabled 1 enabled, other values are selected by DIP switch	Read & Write​	16 bit integer​	3​
113​	Cable function selection 0, Socket function selection 1 by DIP switch	Read & Write​	16 bit integer​	3​
114​	DLB function selection 0 disable 1 enable, other values are selected by DIP switch	Read & Write​	16 bit integer​	3​
115​	PID control parameter P of DLB	Read & Write​	16 bit integer​	100​
116​	PID control parameters of DLB I	Read & Write​	16 bit integer​	1​
117​	DLB PID control parameter D	Read & Write​	16 bit integer​	100​
118 & 119​	Controller ID number up to 9 digits	Read & Write​	32 bit​	​
120​	Rated temperature	Read & Write​	16 bit integer​	​
121​	Temperature correction (Input how much difference between real and display)	Read & Write​	16 bit integer​	​
122​	Start Temperature	Read & Write​	16 bit integer​	​
123​	Stop Temperature	Read & Write​	16 bit integer​	​
124​	Frequency correction(Input how much difference between real and display)	Read & Write​	16 bit integer​	​
126​	Pole option:1P 3P( Default is 1P)	Read & Write​	16 bit integer​	​
127​	Pole selection: 1P 3P Default: 1	Read & Write​	16 bit integer​	​
128​	The first gear current setting value PWM	Read & Write​	16 bit integer​	1667​
129​	The second gear current setting value PWM	Read & Write​	16 bit integer​	2167​
130​	The third gear current setting value PWM	Read & Write​	16 bit integer​	3333​
131​	The Fourth gear current setting value PWM	Read & Write​	16 bit integer​	4167​
132​	The Fifth gear current setting value PWM	Read & Write​	16 bit integer​	5333​
133​	The sixth gear current setting value PWM	Read & Write​	16 bit integer​	5333​
134 to 139​	Spare	Read & Write​	16 bit integer​	​
140​	Software version	Read Only​	16 bit integer​	​
141​	Current working status: Corresponding status 0-13	Read Only​	16 bit integer​	​
142​	PWM value of cable specification	Read Only​	16 bit integer​	​
143​	RFID status 00 not selected 01 IC card not operating 02 IC card closed 03 IC card open	Read Only​	16 bit integer​	​
144​	Lock status 00 not selected 01 locked 02 unlocked 03 fault	Read Only​	16 bit integer​	​
145​	The current current, the decimal place is determined by the value of the reference current	Read Only​	16 bit integer​	​
146​	Current value of charging pile 0-200.0A	Read Only​	16 bit integer​	​
147​	RCMU status 00 Not selected 01 Normal operation 02 Self-check failed 03 There is leakage in the charging circuit	Read Only​	16 bit integer​	​
148​	Current voltage value of charging pile 0-500.0V	Read Only​	16 bit integer​	​
149​	Current power value of charging pile 0-22000W	Read Only​	16 bit integer​	​
150​	Calibration value AD value of reference current	Read Only​	16 bit integer​	​
151​	The PWM duty cycle corresponding to the current set by the rotary switch	Read Only​	16 bit integer​	​
152​	Current output PWM duty cycle	Read Only​	16 bit integer​	​
153​	Control Pilot positive voltage	Read Only​	16 bit integer​	​
154​	Control Pilot negative voltage	Read Only​	16 bit integer​	​
155​	Extra small current count	Read Only​	16 bit integer​	​
156​	Small current count	Read Only​	16 bit integer​	​
157​	Temperature	Read Only​	16 bit integer​	​
158​	Temperature AD value	Read Only​	16 bit integer​	​
159 to 160​	Spare	Read Only​	16 bit integer​	​

The most useful ones I've found so far are this subset of the full table:

Reduced table of useful Modbus registers​

Register Address​	Description​	Read/Write​	Data Type​	Default​
89​	Remote start and stop (0 invalid, 1 start, 2 stop). State is persistent over a power failure.	Read & Write​	16 bit integer​	0​
100​	Device address, range is 1 to 255. Set to 52 for test device	Read & Write​	16 bit integer​	255​
109​	Output PWM write funct. 6 to this register to set duty cycle% x 100. i.e. 16A = 26.67% = 2667 = 0A6B	Read & Write​	16 bit integer​	9000​
112​	Lock function selection 0 disabled 1 enabled, other values are selected by DIP switch	Read & Write​	16 bit integer​	3​
141​	Current working status: Corresponding status 0-13	Read Only​	16 bit integer​	​
151​	The PWM duty cycle corresponding to the current set by the rotary switch	Read Only​	16 bit integer​	​
152​	Current output PWM duty cycle . Read this to see what the EVSE is signalling to the vehicle	Read Only​	16 bit integer​	​

I've managed to read register 89 (0x59) to get the on/off state, and I've also been able to read register 152 (0x98) to get the set PWM on the control pilot, from which the current can be derived by multiplying this value by 0.006 (the PWM is in control pilot period in µs). I can also set the charge current by writing a valid PWM period (in µs) to register 109 (0x6D).

I've got the On/Off function working reliably in Home Assistant, and have managed to use a lambda in the ESPHome yaml to read back confirmation of the on/off status OK. I've also managed to partly get the charge current control working, writing a PWM value to register 109 and then reading back the set current from register 152. I've not yet managed to get the scaling right in the ESPHome yaml, so I'm having to send the raw PWM period. I have got scaling working when reading register 152 though, so Home Assistant is displaying the set charge current in A, rather than PWM period. I suspect I'm not using the "number" function correctly, TBH, although the yaml compiled and loaded OK.

The hardware stuff is pretty easy to hook up and get working. One challenge I had initially was with the default Modbus address of 255. This is the broadcast address, so fine if you only have one Modbus device connected. If you have more than one then it's a PITA. I hard wired the ETEK EVSE to a PC, using a USB to RS485 adapter, and then manually changed the Modbus address to something within the normal range, so between 1 and 254. This resolved the broadcast problem and also allowed me to do some basic testing, sending hard coded Modbus commands and reading back the data from the EVSE module. So far it's been rock-solid reliable, even when running over WiFi via the ESP8266, which is one reason I've persisted with it.

This EVSE has a whole host of functions that can do far more than is needed for a straightforward smart charge point. Quite amazing for something that cost under £34, including shipping from China. It can also drive an add-on LCD display, although TBH this is of very limited usefulness. There are two versions, one that has outputs and feedback for a charge point with a fixed outlet, the other for a tethered charge point. It can also do dynamic load limiting, just needs a CT to be connected and the DLB values set.

​

 

I'm tempted. I'd be a good test case: no charge point or Home Assistant yet, good DIY-standard electrical and modest electronics* skill, competent enough to earn my living coding (I started with FORTRAN IV, later renamed Fortran 66, and I've lost track of how many programming languages I've used since). I wouldn't need to rely on this being cheaper than alternatives. I would have to persuade a certified electrician to install and connect up the power circuit. I've no experience whatsoever with YAML or Home Assistant, but I can learn.

* Modest electronics skill = I am confident I will not pick up the soldering iron by the hot end.

 

I know all too well the pain of translated Chinese documentation. Part of my day job is integrating with inverter cloud APIs. One of them is basically just the modbus interface exposed over HTTP so this is not alien to me.

Do you have a GitHub account to facilitate easier sharing of code?

 

I've spent hours trying to decode the patchy Chinese documentation. I've attached the datasheet, but it's definitely incomplete, as well as having a lot of confusing translations. It would be very easy to just expose the RS485 Modbus connection over TCP, using something like this Elfin EW11: http://www.hi-flying.com/elfin-ew10-elfin-ew11

I'm using one of those to send RS485 Modbus from an energy meter in the garage to Home Assistant, over WiFi. It works OK, but I thought it was a bit too bulky to use for a charge point (although it would fit in the box I'm using, it'd just need an external antenna, as it has an SMA connector on the end).

Using an ESP8266 is cheaper, smaller, plus it offloads a fair bit of the grunt work from Home Assistant, so seemed a better option to me.

I haven't thought about Github, TBH, but it seems to make sense. Not being a coding person means I tend to approach things from the hardware side first, then worry about getting the software to do what I want (and I'll freely admit that the software side of things takes me much longer to sort that the hardware!).

 

Even though I think version control is amazing, I do find myself not using it on personal projects I'm just throwing together. For collaboration it's invaluable and the extra features of something like GitHub are very handy.

I'm sure I've got a spare D1 mini in the box. I don't think I have any RS485 bits though so would have to get that ordered.

Could I get away with just the EVSE module in its own, powered up on the desk? I don't think I'd need a functional charger to the ESPHome side. Just something to test the code with and then send it over to you for integration testing.

 

Even though I think version control is amazing, I do find myself not using it on personal projects I'm just throwing together. For collaboration it's invaluable and the extra features of something like GitHub are very handy.

I'm sure I've got a spare D1 mini in the box. I don't think I have any RS485 bits though so would have to get that ordered.

Could I get away with just the EVSE module in its own, powered up on the desk? I don't think I'd need a functional charger to the ESPHome side. Just something to test the code with and then send it over to you for integration testing.

I will have a look at opening a Github account and see if I can work out how to upload to it. My code is almost certainly laughably poorly structured, though !]

I can send you my spare ETEK module and also a spare RS485 PCB, if you've got a D1 Mini lying around. PM me and I'll pop them in the post. You can certainly run it without the contactor, case etc for testing, just needs a mains cable and a cut down Ethernet cable to connect the RS485 board to the ETEK module.

The other thing that's very useful is a vehicle simulator, so the module can be fooled into thinking that a vehicle is plugged in and requesting a charge. Very easy to knock up a simple one, that doesn't simulate faults as well. Circuit is below.

 

Cool project guys. Giving Open EVSE a run for its money. If you can get this packaged and easy to install, I see a huge market. I paid 1800 euros for my EVSE, installation included. That is a lot of money for a power outlet with lipstick and a blonde wig.

 

Mine was cheaper but didn't come with lipstick or wig. Might have paid more.😎

 

This looks very interesting. I haven't got my head around HA yet, I'm just using an RPi running a Python script to control my solar inverter. Being able to integrate a charger with that would seem to be ideal. I will follow with interest. Github is easy to use, so it seems the perfect place to collaborate.

 

Fully in agreement about Github - widely recognised, free to use, reliable, just what is needed for an open-source collaboration. I wish they'd used a less horrible version management core than Git, but that ship has sailed, and most of the nasties are safely insulated.

@Jeremy Harris - that test circuit diagram can't be right, because the wire at the top right corner has shorted out the 1N4148 diode.

 

Thanks, finger trouble from me editing the schematic for the more comprehensive test box that I made for testing charge point installations. I've edited that post, when I removed the "diode test" button I accidentally created that short!

The full diagram for the plug-in test box I made is below, it has functionality that isn't needed to just get a charge point to respond to the "plugged in" and "request for power" signals:

The above simple test circuit is what's inside this charge point test box:

I've also attached the "manual", such as it is, for the ETEK EVSE module. I'm still working through a better translation of this, based on testing, as some of the descriptions of functions are about as clear as mud. I suspect some sort of automatic translation was used to convert the Chinese manual into English, as a lot of the terminology is confusing (for example, I think that "pile" means battery, in the sense of a battery being a Voltaic Pile - not exactly normal English!).

 

So it wasn't just me not happy about the shorted out diode😀
As for git, hard to learn and understand, but I suspect it's the best. I use a small subset of its capabilities for all my coding projects, even though it's just me at home.

 

As for git, hard to learn and understand, but I suspect it's the best. I use a small subset of its capabilities for all my coding projects, even though it's just me at home.

If you don't need compatibility with Github, Mercurial is nicer than git. I've been using Subversion at work, which has a single centralised master database so not suitable for widely distributed work with multiple independent developers (or teams), for maybe 20 years now. I like that and am used to its concepts. Linus Torvalds hated CVS, one of Subversion's predecessors, so much that he made every possible opposite choice when designing git, and threw out several babies with the bathwater he disliked. Git has good features, but its only critical winning points are that it's distributed and it's on Github.

 

Crikey, I'm glad you guys know what you're doing. The thought of this scares me.

I once installed underfloor heating in three bathrooms. After getting out of the shower I could hear a high-pitched ringing noise, like a distant burglar alarm. I was trying to figure out where the noise was coming from, I put my ear next to the chrome towel radiator and got a little shock.

I then got one of those live tester pens and started touching it on metal things in the en-suite. It lit up like a Christmas tree on basically everything in the room.

I walked out gingerly.

I rechecked my wiring and realised the earth cable had come lose on the controller.

That was the last time I did any home electrical stuff.

I should probably by writing this via a séance.

 

Crikey, I'm glad you guys know what you're doing. The thought of this scares me.

I once installed underfloor heating in three bathrooms. After getting out of the shower I could hear a high-pitched ringing noise, like a distant burglar alarm. I was trying to figure out where the noise was coming from, I put my ear next to the chrome towel radiator and got a little shock.

I then got one of those live tester pens and started touching it on metal things in the en-suite. It lit up like a Christmas tree on basically everything in the room.

I walked out gingerly.

I rechecked my wiring and realised the earth cable had come lose on the controller.

That was the last time I did any home electrical stuff.

I should probably by writing this via a séance.

There's a very good reason that electricians dead test a new installation before making it live, it's to try and reduce the risk of something like that happening. A lot of DIY electrical issues result from a lack of testing, which isn't surprising, given the high cost of test gear. Even a secondhand MFT is going to be a couple of hundred pounds or more, but without one there is no real way to know if the work done is properly safe, although a decent multimeter can do the basics.

Non-contact voltage testers are better than nothing, but are a VERY unreliable test device for checking the safety of something. They have a place when quickly trying to find live conductors, but their main failing is that they won't reliably find something that is live. Most of the time they will, but to work they rely on the person holding the pen to provide a high impedance path through their body to earth, and there are locations in a house where that may not be good enough to make the pen light up.

The standard process after completing an installation is to dead test (i.e. test without the power on) to ensure that things are safe to power on, then live testing to check safety device functions and functionality of the bit of kit that's been installed. This is detailed in Section 643 of the wiring regs, but helpfully TLC have provided a useful guide on their site: TLC Electrical Supplies Note that the very first test is "Continuity of protective conductors". This is the one that would have picked up the protective earth fault you had!

 

I hear you, I use Steve the Sparky now. He's done a lot of work for me over the years and after watching him test everything with his fancy equipment, I was like hmmmmm yeah he can do it from now on.

 

There's more to the UK regulations about 'smart' chargepoints than just making it controllable.

These days:
It must support the ability to connect to an OCPP 1.6 backend of the owner's choice.
Electric Vehicles (Smart Charge Points) Regulations 2021

If it's sold as a product, then default passwords must not be guessable, no default factory passwords.
Product Security and Telecommunications Infrastructure Act 2022, but that's also covered by Electric Vehicles (Smart Charge Points) Regulations 2021

Support out of the box is expected for Demand Side Response services (which surprisingly isn't standardised or specified, so how are chargepoint manufacturers supposed to code it?), where the charge point owner can opt in to having their electricity suppier or DNO turning down or off the available current it draws from the grid.

Personally, if I was using that protocol controller, I'd just get the RS485 interface hooked up to a microcontroller like an ESP32 and run the 'smarts' there rather than relying on home assistant to control it. By all means make it controllable from home assistant, but if you're considering shipping as a finished product, be aware that not everyone has a home assistant install, some use node red, some use Domoticz, some use OpenHab,but the majority of people with a 'smart home' system probably just think that Google Home or Amazon Alexa is such a thing.

If you look at the guts of many commercial charge points, they do just this; they have one microcontroller doing the essential safety stuff and low-level protocol control, and another doing the internetty bits. A Pod Point Solo 3 typically uses a TI microcontroller for the low-level protocol controller, and an esp32 to talk to pod-point's mothership (they skirt around the regulations by getting the OCPP interface in their back-end server rather than the chargepoint itself). Openevse uses a atmega328 for the low-level protocol controller, and an ESP32 for the internet stuff (and and you genuinely can connect it directly to back-end systems of your choice, without having to ask anyone else for permission).

 

Personally, if I was using that protocol controller, I'd just get the RS485 interface hooked up to a microcontroller like an ESP32 and run the 'smarts' there rather than relying on home assistant to control it. By all means make it controllable from home assistant, but if you're considering shipping as a finished product, be aware that not everyone has a home assistant install, some use node red, some use Domoticz, some use OpenHab,but the majority of people with a 'smart home' system probably just think that Google Home or Amazon Alexa is such a thing.

If you look at the guts of many commercial charge points, they do just this; they have one microcontroller doing the essential safety stuff and low-level protocol control, and another doing the internetty bits. A Pod Point Solo 3 typically uses a TI microcontroller for the low-level protocol controller, and an esp32 to talk to pod-point's mothership (they skirt around the regulations by getting the OCPP interface in their back-end server rather than the chargepoint itself). Openevse uses a atmega328 for the low-level protocol controller, and an ESP32 for the internet stuff (and and you genuinely can connect it directly to back-end systems of your choice, without having to ask anyone else for permission).

TBH, if it wasn't for the fact that I've been running HA for a few years here I'd perhaps thought about just making the thing host it's own simple web page, although, TBH the coding needed to do that would be beyond me. This has been done by someone else for this same EVSE module, using an ESP8266: EVSE Integration With ESPHome

When I tried this out it set up a very simple site, hosted on the ESP8266, that looked like it had the potential to be useful, but it seemed to be a bit incomplete. I suspect that asking an ESP8266 to host a web interface is perhaps a bit much, although if an ESP32 was used in place of the ESP8266 then I'm sure that would be fine.

There's so much out there involving ESP8266s and ESP32s that it seems sensible to focus on that platform for the connection side. I'm not sure what the processor is in the ETEK module, but as it seems to have access to all the sensors and controls that could be needed over RS485, including setting up the circuit protection stuff, like the open PEN fault limits and the DC tolerant RCD function (if the £15 add-on RCMU module is fitted), so it looks to be good enough to handle pretty much anything that might be required.

I'm not in this to produce a product, all I really want to do is have a charge point that integrates well with Home Assistant. There does seem to be the potential for someone to make this a commercial product though, especially as the hardware is a fair bit cheaper and more compact than OpenEVSE (not knocking OpenEVSE, it's a very good project, although a bit North America centric and quite expensive).

 

I cant get point why 39R and 100R are added in series to kOhms (above schematics)?

I am thinking to buy some cheap chinese evse around 100-150€ and dissasemble and hack CP to make own remote control switch using (also dissasembled and 'hacked') Tapo p110 which cost around 10€)... next need ic555 simple circuit that will produce 'fake' 1kHz signal to stop charging in position B, and when tapo relay is in postion A will connect original CP from chinese charger to the car.

Project what you intent to do seems complicated from this what I intent to do, and tapo switches are very well implemented in Home Assistant ( i dont need it, cos i have my own logic to log data from hybrid solar into postgres database).

 

I cant get point why 39R and 100R are added in series to kOhms (above schematics)?

Because the standard specifies 1.3 and 2.74 kΩ, which are not in the common E12 resistor value series.

For the project as a whole, the aim is to make a home charge point which meets the UK smart charge regulations. Cruder control won't be able to do so.

 

I wonder why they chose that scheme. Things like 4-20mA current loops and RS485 have been around forever.

 

I think the original intention was to enable construction with minimal discrete component analogue circuitry. Two decades later, it does seem odd that a small microcontroller would be too difficult or expensive, especially as they now have to have WiFi or similar digital connectivity anyway.

 

Pile as a term for battery is common in europe
See

https://en.wikipedia.org/wiki/Voltaic_pile

The voltaic pile was a stack of dissimilar metal disks to give a higher voltage, our equivalent will be stringing coin cells together. I think this is where the Chinese translation comes from

 

Pile as a term for battery is common in europe

Of course, that was the immediate, obvious answer when I saw it used last year. But that interpretation doesn't make sense when you look at the way in which that the word was used in the thread last year. Hence I was pointing out that the obvious answer is not (it seems) the correct one.

 

I remember that, pile there was anyone's guess as it seemed to refer to the electronics on a pole. whereas pile is a term used for batteries in many places.

 

Indeed. I think we have definitely established comprehensively that pile is a term used for batteries in many places.

Hopefully this thread can now get back to the subject of a low-cost, compliant EVSE.

 

Pile maybe means stack, as in the product is the full stack of hardware and software components?

 

It's a common Chinese mistranslation into English. When you read an "EV charging pile" in machine-translated Chinese to English, they mean an EV charge point. The mistranslation appears to have been used for both DC and AC charge points. The more this mistranslation happens, the more it gets used as reference material to train other LLM-based machine translation.

 

...

The basis of this charge point is this ~£34 ETEK EVSE module, that is pretty much a direct replacement for the Rolec EVSE controller (more capable, much cheaper and same LED polarity): https://www.aliexpress.com/i/1005004512138683.html
...

Fantastic thread and great project this. When I follow the Aliexpress link it's only asking £12.09 including VAT. Can that be right??

I'm time poor at the moment, but going to get one anyway at that price, as my existing EVSE setup is (5 year old Rolec, upgraded to Viridian, added WiFi switch on the CP) seems to be on the way out whether I have time to sort it or not.

 

Take care!

The link opens to the price for the RFID card reader add-on, unfortunately there's nothing I can do about that, it's just the way Aliexpress works. You need to scroll across to the right to select either the cable or socket version. For some bizarre reason the selection has the title "color", I can only assume this is some sort of translation issue:

 

I'm still working on this, and have had the test unit powered up, in the garage (not installed or charging a car yet) for the past few weeks. The aim was to do a bit of basic reliability testing and to see how robust the WiFi link is from the house to the garage (the detached garage is ~30m to 35m from the house). So far it's been rock-solid. I have been turning the charge point on and off using the off-peak signal from the house off-peak supply (this uses a cheap Shelly i4, loaded with ESPHome firmware). The Shelly gives an "On" signal as soon as the E7 meter switches on the off-peak loads and I'm using that to, by default, turn on the charge point. It's been reliably doing this for a couple of weeks now, so I'm OK with that bit.

The bit I'm currently working on is making a remote control for the charge point, so I can increase or decrease the charge current advertisement using a simple manual control. The reason for this is that using an automated method (using data from the Home Assistant solar generation sensing, the home battery SoC and charge sensing and the hot water system charge sensing) is less than perfect. The problem is that I can look at the weather forecast and make a decision as to which load I think needs to take priority. If the forecast was always accurate I could automate this, but it isn't! I need to compare the forecast with what I can see out of the window, and account for some vagaries, like the home battery not being able to accept a charge if it's already been to 100% that day, and has discharged to, say, 96% (it has a 95% SoC charge acceptance threshold for that condition).

This means that there are times when it makes sense to divert some of the solar generation to car charging*, rather than let either the house battery or hot water get first dibs. To do this manual control until now, I've used the manual charge current control knob on the existing charge point. This works, but it's a nuisance to have to keep trekking up and down the drive to adjust it, hence the need for a remote control. I'm currently playing around with a rotary encoder with a built-in circular TFT display, which seems to work well. The display shows the advertised power from the charge point, the rotary encoder changes that as required.

Next stage is to try and get this tidied up and properly integrated into Home Assistant, so that everything can be selected/controlled from menus running on the ESP32 in the rotary encoder/display. The intention is to have four options, off, automatic solar charging, off-peak charging and manually controlled charging.

More to follow . . .


* We can't get paid a decent rate for export (can't have a smart meter - no signal) so, because we're on the old (very generous) deemed export payment, it makes a lot of sense to self-consume as much of our solar generation as possible, at least until 2034 when our FiT agreement expires. I know not everyone will be in this fortunate position, and for them, self-use of excess PV generation may well not make any sense. That does have the advantage of very much simplifying charge point control!

 

It may also make sense to bias towards higher car charging/battery discharging so that you can get back to battery comfortably tracking solar territory.

I've done something similar to charge the car on solar:
trigger: high battery charge power.
lots of checks as conditions, such as the sun is indeed up, not during free session, not during IOG, car is plugged in, etc.
start charging at 5 amp (Tesla's minimum). Also turn on charging on solar input boolean.

Then another automation fires on every MQTT message from battery. Tracking battery charging (thus solar excess) and setting the car's charging amp accordingly.

 

It may also make sense to bias towards higher car charging/battery discharging so that you can get back to battery comfortably tracking solar territory.

I've done something similar to charge the car on solar:
trigger: high battery charge power.
lots of checks as conditions, such as the sun is indeed up, not during free session, not during IOG, car is plugged in, etc.
start charging at 5 amp (Tesla's minimum). Also turn on charging on solar input boolean.

Then another automation fires on every MQTT message from battery. Tracking battery charging (thus solar excess) and setting the car's charging amp accordingly.

I think you're right, as at the moment I make a judgement as to both which car to charge, and whether or not it makes sense to charge, based on several other parameters, like when either of us are next planning to use our cars, what I think the weather is going to do, how far any planned future trips may be, etc. Translating judgements like this into code is tough, as often the decisions are based as much on a feel for how reliable all the decision-forming data may be as the actual data itself.

It's one of those automation conundrums that very much challenges the whole algorithmic approach, as people tend not to make decisions based purely on the hard data that they have to hand, they bias those decisions based on their learned experience, their risk appetite, as well as a whole host of hard to quantify emotionally-driven reasons.

At the moment I have access to more than enough data, varying from pretty accurate local measurements, to the vagaries of Met Office provided forecasts for our nearest weather station (Teffont Magna for those that might still be vaguely interested). I've already had my fingers burned by relying on historical weather data from that station, only to find out after completing our house than the mean temperature here (at the bottom of a steep-sided valley) is around 1.5°C to 2°C warmer (that's enough for us to need a fair bit of summer cooling, albeit with a fair bit less winter heating).

 

hi, i have some trouble getting any communications from my controller. i currently have it set up with 255 as the adress, I dont have the usb to RS485 yet. the baud rate and other settings are as described in the user manual for the controller. is there any tricks to get it to communicate?

 

hi, i have some trouble getting any communications from my controller. i currently have it set up with 255 as the adress, I dont have the usb to RS485 yet. the baud rate and other settings are as described in the user manual for the controller. is there any tricks to get it to communicate?

Jeremy previously noted

The hardware stuff is pretty easy to hook up and get working. One challenge I had initially was with the default Modbus address of 255. This is the broadcast address, so fine if you only have one Modbus device connected. If you have more than one then it's a PITA. I hard wired the ETEK EVSE to a PC, using a USB to RS485 adapter, and then manually changed the Modbus address to something within the normal range, so between 1 and 254. This resolved the broadcast problem and also allowed me to do some basic testing, sending hard coded Modbus commands and reading back the data from the EVSE module.