Home Assistant intergration

[jeremypoulter]

The current Home Assistant integration is a bit outdated and with the new features in both OpenEVSE and Home assistant we can do better:

• Auto discovery
• Setup via Home Assistant UI
• Real time updates via web socket
• Support energy API
• Use newer OpenEVSE APIs

Sensors

• Current
• Voltage
• Power?
• Session Energy
• Total Energy
• Status
• Temps
• Vehicle connected
• Rssi

Actions

• Max current
• Charge current
• Manual Override
• Schedule
• Divert mode

https://developers.home-assistant.io/docs/creating_component_index

Update: @firstof9 has put some great work into a Home Assistant intergration: https://github.com/firstof9/openevse

[andriuskr]

Is there any ETA for updating integration? Trying to accomplish charging current regulation in home assistant by whole home usage (limited home electricity input) for a while now.

[jeremypoulter]

Probably not going to be till next month, but no promises...

[doppiaemme]

check this out for the time being:

https://gist.github.com/TonyApuzzo/c0fe22458d4dae0effb47b951b464484#file-openevse2-yaml

[jeremypoulter]

https://github.com/cathiele/homeassistant-goecharger

[jeremypoulter]

https://github.com/tmjo/charger-card

[drobtravels]

Hi @jeremypoulter, I'm very interested in collaborating with you to help get this out, as much as my limited time / skillset will allow. I don't have much python experience, but have managed to create a simple Home Assistant integration in the past.

OpenEVSE seems to align well with Home Assistant's ethos (full local control) so I would expect this to be a popular integration.

Do you have a WIP fork yet we could collaborate on?

I'm also curious if you have thoughts on how to accomplish these two items. I believe this may require updates to the OpenEVSE wifi firmware?

• Auto Discovery
• Real time updates via web socket

[jeremypoulter]

Sorry, I have not progressed more than creating the ticket and doing a bit of research. Would be great to get some assistance on this however.

Auto Discovery

This should be fairly simple via mDNS, Home Assistant already supports this as a discovery type. To make it a little simpler we may need to add a few records to help filter the devices, similar to what I have done in EmonESP.

Real time updates via web socket

Everything that is sent over MQTT is also sent to a websocket to update the web UI so all that is needed should be in place already.

Also note I am working on documentation of the API via #245 / https://openevse.stoplight.io/docs/openevse-wifi-v4

[jeremypoulter]

Also on the mDNS/Zeroconf discovery, see https://developers.home-assistant.io/docs/creating_integration_manifest#zeroconf

[jeremypoulter]

As I had looked it up, I added the required mDNS tweaks, #260

[firstof9]

I've been working on this a bit myself:
https://github.com/firstof9/openevse

[omriasta]

I've been working on this a bit myself: https://github.com/firstof9/openevse

This integration is great! Exactly what I was looking for. It would be great if you could add an option to use mqtt in the config flow as well!

[firstof9]

It would be great if you could add an option to use mqtt in the config flow as well!

MQTT has it's own integration you can use.

This is specifically geared towards using the HTTP API as much as possible.

[omriasta]

It would be great if you could add an option to use mqtt in the config flow as well!

MQTT has it's own integration you can use.

This is specifically geared towards using the HTTP API as much as possible.

Yep, I have MQTT setup as well. Was thinking of having them combined all in one integration where one could select if they setup using http or mqtt. My specific setup is I have 2 units, one is on the local network and the other is remote but publishing to my mqtt broker.... I guess big picture if we want to replace the current integration, having both options combined into one would be great for all uses.

[firstof9]

Please open a feature request (on my repo), I'll see what I can do, I can't test mqtt right now due to openevse not connecting to my broker for some unknown reason.

[jeremypoulter]

@firstof9 are you using a secure connection for MQTT? could be certificates is so, but do need to do work on reporting failures. Maybe open another issue and we can discuss there?

[drobtravels]

Just putting in my 2 cents since I had originally said I would work on this. Personally I won't be able to use a Home Assistant integration with the new API until #272 is resolved.

For now I'm using the gist referenced above. Unfortunately its not reliable due to #135

[jeremypoulter]

Trying to get to both of those, hopefully soon

[ruimarinho]

@jeremypoulter have you considered using ESPHome? It would probably mean a big rewrite but it brings so much out of the box that I thought I'd leave the suggestion here.

[firstof9]

ESPHome wouldn't really fit for this kind of hardware/project.

[jcsogo]

I have started to use the integration from @firstof9 (thanks) - I see that there are still some stuff to be implemented, like the ability to set the charge mode or even the manual override. But there is one thing that surprises me, which is that the only way to get the Level min and max current is through a RAPI command. This information should be provided with the level, as it is the basis to show a proper menu to manually select the current. Right now @firstof9 is hardcoding values up to 48A, which is over what a regular charger would support in Level 2 configuration in Europe.

@jeremypoulter any plan on providing this information through the API?

Many thanks to you all for your fantastic software.

[jeremypoulter]

I am currently working on that as part of #140

[firstof9]

I see that there are still some stuff to be implemented, like the ability to set the charge mode or even the manual override.

It's still a work in progress, as more API stuff get's fleshed out the move function I can give the integration.

[rbray89]

Fully MQTT doesn't seem possible at the moment due to RAPI deprivation and no MQTT equivalent for the HTTP API.

[glynhudson]

Fully MQTT doesn't seem possible at the moment due to RAPI deprivation and no MQTT equivalent for the HTTP API.

MQTT API is now available since this PR has been merged which should be equivalent to HTTP API #379. Big thanks to @KipK

Se docs: https://github.com/OpenEVSE/ESP32_WiFi_V4.x/blob/master/docs/mqtt.md

[glynhudson]

I've been working on this a bit myself: https://github.com/firstof9/openevse

Nice work! That's a really nice integration. The only thing that's missing is the ability to set a schedule and the ability to manually start / stop a charge.

[firstof9]

set a schedule

This will likely be setup as a service call in Home Assistant.

the ability to manually start / stop a charge.

Are you referring to the override on that? If so, this will likely be a service call in Home Assistant as well.

[KipK]

About MQTT, I've just added a PR adding /schedule /schedule/set /schedule/clear

There should have everything needed to completely control OpenEvse from Mqtt without any need of RAPI.
If you see something missing on some use case , please share

You can use /claim to manually start / stop, set charge current . It already has bigger priority than timers. /override has highest priority, but there should be few need to use it anymore.

[jeremypoulter]

Home Assistant really should be using the HTTP API, you should probably only use MQTT for control when you can not use HTTP as MQTT really isn't designed for one&to-one comms (it is much better at broadcasting one-to-many events) and although you can do it you will get much more reliable results when using HTTP particularly around error handling.

[KipK]

Not completely agree but it's a matter of taste.
With QoS and Last Will, it's quiet resilient.
With many different devices/sensors/actuators using different protocols ( zwave, ZigBee, http, some binary proprietary stuff,etc ), I kinda like to unify everything over MQTT.
You make me remind I've wanted to add an error topic too 😊

I don't use home-assistant here, but an equivalent solution ( Jeedom ).
With many different devices without Mqtt, it would need different addons for each protocol here.

[firstof9]

There's a 3rd feature I'm still working on as well for Home Assistant, auto discovery, but I can't seem to find any mDNS for OpenEVSE.

[omriasta]

It appears this was added at some point...not sure if this helps?
#260

[firstof9]

Doesn't seem to work?

firstof9@firstof9:~$ avahi-browse -t -r _openevse._tcp
firstof9@firstof9:~$ 

[omriasta]

Hmmm...I ran:

avahi-browse -at
avahi-browse -t -r _openevse._tcp

And got a response....it did not work until I first ran with -at

[firstof9]

Ah just showed up after upgrading to 4.1.4
Strangely after firmware upgrading this is the only time I can get MQTT to connect as well. Weird stuff.

[fhteagle]

+1 for the integration from @firstof9 . Just installed in my HomeAssistant docker instance, starting to test it out now.

[fhteagle]

@glynhudson , you can probably close this issue as well. The integration at https://github.com/firstof9/openevse is working well, and has a responsive developer.

[glynhudson]

Agree, that component works great. I use it myself, @firstof9 is doing a great job 👍