Question

Hello,

I was advised by Giedrius Pupeikis to post here instead of GitHub, I have received my TeltoCharge about two weeks ago and it was installed last week.

Besides the charger being a nicely designed product in terms of hardware and outside, the software/firmware functions are a bit disappointing right now

I spent about one day trying to update to latest firmware, then it turned out that the device I purchased accepts only pre production firmware which is very odd for me. The other problem is with Dynamic Load Balancing, but we found out that the issue is that the energy meter I am using is communicating at another serial baud rate, and it doesn't support baud rate higher than 19200bps. I would like to ask if it would be possible to implement configuration option for the smart meter serial communication settings. I understand that the meter I am using is not among the supported ones, but since it is a popular, reliable and cheap option on the market, it could be even a selling point for the product if it can be supported by the hardware and the firmware.

OCPP integration works mostly well with Home Assistant, some bugs reported by Rado are also present at me (when a charge was finished it is not possible to restart charging until connector is reconnected or charger is rebooted), I created a template sensor to have the actual power supplied to the car based on multiplying the voltage and current import sensors, and it works reliably.

I don't know if it would be possible to enable plug and charge if the charger is connected to an OCPP central station. 

Because when OCPP is enabled, charging app shows NFC card required and if the cable is plugged in, charging only starts if charge control is set to enabled in Home Assistant.

Additionally, Availability switch in Home Assistant does not seem to have any effect in my case.

I am using v1.3.12L firmware, as I could not update to normal 1.3.12 because it was always stuck at 0%

thank you

Daniel

Answer 1

Hello danielszilagyi,

1. So officially we support only carlo gavazi meters currently. This means we can't make any guarantees that it would work with other energy meters as it may have different protocol also. We have plans to add configuration for load balancing, but can't tell with which firmware release will be with it at this moment. Also we have plans to support more meters in future. Can I ask you what meter are you using currently?
2. Yes, we registered bug about charging restart.
3. EVC1 devices don't have the hardware,  that would allow it to support plug and charge. We are planning to release a device next year, which would support that. Plug & charge use cases are dedicated for public charging. Can I ask you why do you need it for home charging?
4.  I do not know what "charge control"  & "Availability switch" means in home assistant currently, so hard to say what commands it send in OCPP protocol. We do have plans to test with home assistant by ourselves.
5. From V1.5.0 there will be only one firmware for update it will detect it automatically. L versions is totally fine as without L. You will be required to update V1.4L in future.

Best Regards,
Giedrius Pupeikis

Comments

Hi Giedrius,

1) The meter is an Eastron SDM72D-M (MID certified, RS485 modbus output) and I can provide serial output dump of the meter if that helps. The flaw is that the meter only support 19.2kbps serial communication maximum. I am happy to volunteer for testing as well.

3) Sorry It was my confusion, under "plug and charge" I just wanted to know if it is possible to configure the charger to start charging automatically when it is configured to be connected to an OCPP central system, and a car is connected to the cable.

Right now the charging would start if it is triggered via OCPP, I would just like to know if this can be configured on the charger side, or this should be solved in the central system configuration. It did not come to my mind that this is a charging protocol as well, but now I remember it is a protocol to identify the vehicle.

4) Happy to provide debug information if required, these are virtual entities created by the Home Assistant integration, let's wait for the next firmware release to see if it was improved

5) I would like to know what is the difference between charger that is accepting the "L" version as I read on the website that production units should have the ability to be updated with production firmware, and my understanding was that I am purchasing the final product.

thank you for your prompt answers, have a nice day

Daniel

---

1. Well, I can't assure you that this would be supported in future. As I know there will be more supported devices but can't say which one. Currently default baud rate is 9600 for charger. As you say 19200 is maximum then maybe you can configure meter to lower baud rate? But also if meter registers do not match then it won't work.

3. Well, from other OCPP server providers I have seen solutions where they wanted to automatically start charging when car is connected. So they send remote start transaction OCPP command every time connector becomes preparing so it's automatically starts charging.

5. L version device was started to be manufactured before mass producing. Basically differs by internal data structure.

---

Hi Giedrius,

Are you absolutely sure the default rate is 9600bps? Because I was informed by the reseller of the Teltocharge that Carlo Gavazzi meter defaults are 115200/8n1. We were positive, that the DLB is not working due to the meter communicating at a lower speed than Teltonika would expect. If the communication is 9600bps, I might have been on the wrong path. We tried first with 9600bps, A to B, B to A, GND to GND

 The registers should be the same in theory, since it's a standard. Can I provide input for you to check and compare?

I will implement the charging autostart based on connector Preparing state.

So this is a fully finished product even though the L version?

thanks,

Daniel

---

danielszilagyi,

Yes, absolutely sure that we are using 9600 bps. Also talked with colleagues and they say it won't work because we also reading identification register and if it's do not match, then we prompt error/warning so it won't work either way. 

I think this decision was made from managers cause they don't want support team to troubleshoot problems that would occur if everyone would start using unreliable meters and something happens wrong.

Well, R&D adding new features and fixing occurring bugs but yeah it's finished product. There is any more recent product than that you have one.

Best Regards,
Giedrius Pupeikis