Pulsar Plus: OCPP not connecting

[FredTheEd]

Hello,

I'm new in the HA world and I am struggling for hours to make my wallbox speak to my Nuc via OCPP.
Am I overlooking sth.? Do I need to configure the websocket by myself? Do I need to fill in the password in mywallbox? Where would I set a password in HA?
You must think I'm stupid. I'd be very thankful for any help.

Fred

PS: I rebooted all components several times.

[lbbrhzn]

@FredTheEd., your configuration looks ok. Passwords are not needed, since they are currently not checked.
I've got a wallbox pulsar plus myself, and this is working fine with the OCPP integration for home assistant.

Can you confirm that you can reach your homeassistant page using http://homeassistant.local:8123 in your browser?
If not, then you could try to use the address you use in your browser instead, or the IP address, with port 9000.

[FredTheEd]

@lbbrhzn, thank you for your reply! Your link is working perfectly.

[lbbrhzn]

Is your wallbox connected to the same WiFi network as your home assistant setup, or is it using some guest network perhaps?

[FredTheEd]

It's in the same network.

[lbbrhzn]

Is there a firewall active on your NUC?
I assume you've tried resetting your wallbox?

[FredTheEd]

Still, the same problem. Maybe the websocket isn't working properly. How could I check this?

[FredTheEd]

the websocket seems to be the problem, any idea how to fix that?

[lbbrhzn]

login to your home assistant setup, and from command line type
netstat -l | grep ':9000'.
If all is well you will see a line like this:
tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN

[lbbrhzn]

Would also be good to enable logging for OCPP and show me the log file.
If the integration is unable to create the websocket, it should contain an error message.

[FredTheEd]

there is no :9000

Logs where OCPP is mentioned:

There are no new issues!

2021-12-20 18:33:09 WARNING (SyncWorker_0) [homeassistant.loader] We found a custom integration ocpp which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant
2021-12-20 18:33:13 INFO (MainThread) [homeassistant.bootstrap] Setting up stage 2: {'tag', 'zeroconf', 'usb', 'dhcp', 'blueprint', 'ssdp', 'input_datetime', 'persistent_notification', 'forecast_solar', 'default_config', 'map', 'media_source', 'group', 'history', 'input_number', 'sun', 'script', 'system_health', 'ocpp', 'input_text', 'automation', 'met', 'scene', 'local_ip', 'logbook', 'network', 'timer', 'esphome', 'counter', 'my', 'energy', 'mobile_app', 'updater', 'zone', 'trace', 'input_boolean', 'wallbox', 'tts', 'input_select', 'hacs'}
2021-12-20 18:33:25 INFO (MainThread) [homeassistant.setup] Setting up ocpp
2021-12-20 18:33:25 INFO (MainThread) [homeassistant.setup] Setup of domain ocpp took 0.0 seconds
021-12-20 18:33:25 INFO (MainThread) [homeassistant.components.sensor] Setting up sensor.ocpp
2021-12-20 18:33:26 INFO (MainThread) [homeassistant.components.switch] Setting up switch.ocpp
2021-12-20 18:33:26 INFO (MainThread) [homeassistant.components.number] Setting up number.ocpp

I have also included this text in the configuration.yaml, not sure if it even had an impact:
logger:
default: info
logs:
custom_components.ocpp: critical
websocket: debug

[lbbrhzn]

I can't see anything strange in your logs. The socket should be visible with netstat -a if you execute this from the Home Assistant CLI.
Not sure if that works from core-ssh as well.

Websocket response should be like this:

[FredTheEd]

I can find the :9000 using the CLI directly on the NUC and the connection via weasel looks good to me, too.

[lbbrhzn]

Ok, then the home assistant side looks ok, and it is the wallbox / network side your should look at.
Maybe use WireShark to monitor the network traffic?

[FredTheEd]

I'm not familiar with WireShark. I installed it on my Laptop and I can see the traffic on wifi, bluetooth and LAN, but how can I check the connecttions of my wallbox?

[lbbrhzn]

You need to run it on your NUC, or capture the traffic on your router.

[lbbrhzn]

Any luck with WireShark?
There's a new firmware version for the Pulsar, with some network connectivity improvements.
See https://support.wallbox.com/na/rn/release-of-22-december-2021/

[FredTheEd]

Thank you for asking. I left town for Xmas. So I’ll give it a try in a couple of days. Keep you in the loop. Thank you so much for your support. I’m so looking forward to build up an EMS with HA, integrating solar panels, wallbox and air conditioning/heat pump.
merry Xmas and a happy new year!

[lbbrhzn]

I noticed that I had connection issues with the new firmware myself. After some debugging with WireShark I saw that the wallbox tried to resolve the hostname 'ws'. I then removed the 'ws:' prefix from the OCPP url setting for the wallbox, and my connection issues were resolved.

Happy xmas!

[GrantKeymer]

Hi Ibbrhzn,

I'm new here too and having a similar problem to FredTheEd. I also have a Wallbox Pulsar Plus which has been working well for more than one year. The latest software 5.5.10 is installed in my Pulsar Plus and I have a strong WiFi signal from an Access Point nearby.

I've followed your instructions about removing 'ws://' from the Websocket URL and now my charger shows 'Locked' and 'OCPP Connecting'.

Using netstat -a shows this...

tcp 0 0 0.0.0.0:9000 0.0.0.0:* LISTEN

So far so good, but I can't find how to enable logging for the OCPP Integration.

I hope you had a great Christmas and thanks very much for your help.

Kind regards,
Grant.

[lbbrhzn]

@GrantKeymer, see https://github.com/lbbrhzn/ocpp#debugging to enable debugging.

[GrantKeymer]

Thanks @lbbrhzn
Now I am another step closer. Where can I find the /config directory as mentioned in Readme.md?

"After a restart detailed log entries will appear in /config/home-assistant.log."

I've tried looking everywhere under the homeassistant user directories ... home, .storage, hacs etc, etc.

But cannot see a /config directory anywhere. As I said, I'm new here but have a little knowledge of Linux.

Thanks again,
Grant.

[lbbrhzn]

You can see the log in your browser, by going to Configuration / Settings / Log / Load Full Home Assistant Log.

[GrantKeymer]

You can see the log in your browser, by going to Configuration / Settings / Log / Load Full Home Assistant Log.

All it says is this...

"2021-12-27 11:31:00 WARNING (MainThread) [homeassistant.bootstrap] Support for the running Python version 3.8.10 is deprecated and will be removed in Home Assistant 2022.1. Please upgrade Python to 3.9."

I am trying to change the environment variables so they point to Python 3.9 instead of 3.8. But I don't expect this has anything to do with OCPP not working.

What do I need to do so I can see the error messages concerning OCPP?

[lbbrhzn]

The warning you see can be ignored for now, it's the ERROR messages that are important.
There is a button at the bottom of that page named 'LOAD FULL HOME ASSISTANT LOG', this will show all log messages.

[GrantKeymer]

I just noticed that HACS and all my integrations, OCPP repository have disappeared after I restarted my PC when trying to get the Java version fixed. So I will have to go through all that again and maybe then the missing OCPP logs will appear.

Many thanks again for your help,
Grant.

[GrantKeymer]

Now I have HACS reinstalled after removing the GitHub rate limit in configuration.yaml.

Then the OCPP Repository reappeared by itself, but I re-downloaded to be sure.

The Full Log File only shows Info and Warnings, no Errors except for this one...

2021-12-27 16:52:22 ERROR (MainThread) [metno] Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'TimeoutError'

It doesn't seem like anything to do with OCPP. Any ideas on how I can get it to work?

Kind regards,
Grant.

[GrantKeymer]

Hello again @lbbrhzn

I've switched to the containerised version of HA using Docker and it seems like a much more stable environment. There aren't any issues such as outdated Python versions to worry about and HACS / OCPP are working fine. I haven't seen any ERROR logs at all and the WARNING about Python 3.8 has now disappeared.

I've been using WireShark to try and sniff packets to/from the Pulsar Plus. I know my PC is listening on ports 8123 and 9000 according to Netstat and I've passed them into the Docker container using the Run command. These are the port mappings I've used...

PS C:\Users\grant> docker port "home-assistant"
8123/tcp -> 0.0.0.0:8123
9000/tcp -> 0.0.0.0:9000

Is TCP the correct protocol to use?

Filtering packets on the IP address of the Pulsar Plus (192.168.1.103) I see the following...

71190 2069.750896 192.168.1.103 192.168.1.200 TCP 74 47290 → 9000 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=4294942741 TSecr=0 WS=128

71219 2070.756419 192.168.1.103 192.168.1.200 TCP 74 [TCP Retransmission] [TCP Port numbers reused] 47290 → 9000 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=4294942848 TSecr=0 WS=128

This pattern repeats over and over every few seconds with the 47xxx number incrementing by 6 or 10 each time. Later sequences are 47296, 47306, 47312 etc.

Another thing I've noticed is that there are no packets with a Destination of 192.168.1.103 (the Pulsar Plus). This would seem to show that the Pulsar Plus is continually sending packets to my PC on Port 9000, but never getting a reply.

@martenjacobs - I see that you also have a Wallbox Pulsar Plus. I would really like to make a contribution to this community, but at present my OCPP connection doesn't work and I can't find out why. I'm an electrical engineer with a reasonable knowledge of TCP/IP and have written software in Assembly Language, Basic, Pascal, HTML etc. So I expect I could learn Python without too much difficulty.

Any help would be much appreciated.

Many thanks,
Grant.

[martenjacobs]

@GrantKeymer To me this really looks like there's no server listening. Are you positive that it's running?
The fact that something is listening according to netstat, could easily be because Docker is probably listening on those ports now so it can pass any connections to the home assistant container.
What happens when you use netcat or a similar tool to connect to the port? Is the connection accepted or refused?
I've set up the server in HassOS, following the instructions from the readme, and didn't have any problems connecting my Wallbox.

[GrantKeymer]

@martenjacobs Thanks very much for your reply. Great to hear you had no problems getting your Wallbox connected under HassOS. It seems like that will be my way forward. So far I've tried using HA Core, running under WSL in Windows and that was a nightmare to be honest. Seemingly simple things such as trying to upgrade the Python version completely broke my installation and I had to reinstall 3 times. Then when I finally got Python 3.9 installed, I could not get the virtual environment to activate, so was unable to run HA.

Therefore I tried the containerised version of HA running under Docker using WSL in Windows. Installation was certainly much easier, and if it wasn't for this comms issue I would pursue it further. My Pulsar Plus has behaved identically when running with HA Core or HA Container so that leads me to believe it's something to do with Windows getting in the way. That's a pity because it makes an ideal test bed for experimentation until I decide whether HA/OCPP is going to be useful with my charger or not.

I will study the docs on Netcat to find out how it works and see if that gives me any clues.

If I don't get anywhere, I will look at buying a suitable hardware platform for HassOS. I already have an Intel NUC running my weather station and video surveillance so I don't want to mess around with it. Also have an ASUS board running a VPN for video streaming so don't want to mess with that either. Maybe a Raspberry Pi or ODROID will be the best idea. Which hardware platform are you using?

[GrantKeymer]

@martenjacobs Thanks very much for your help with using NC. Nmap under Windows is slightly different, but here is the output I got...

============================================================
C:\Users\grant\Downloads\nmap-7.92>nmap -v 192.168.1.200 -p 9000
Starting Nmap 7.92 ( https://nmap.org ) at 2021-12-31 12:01 New Zealand Summer Time
Initiating SYN Stealth Scan at 12:01
Scanning host.docker.internal (192.168.1.200) [1 port]
Discovered open port 9000/tcp on 192.168.1.200
Completed SYN Stealth Scan at 12:01, 0.01s elapsed (1 total ports)
Nmap scan report for host.docker.internal (192.168.1.200)
Host is up (0.00s latency).

PORT STATE SERVICE
9000/tcp open cslistener

Read data files from: C:\Users\grant\Downloads\nmap-7.92

Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds

Raw packets sent: 1 (44B) | Rcvd: 2 (88B)

============================================================

I didn't get "Connection Established" or Refused.

Another thing I noticed when restarting Docker, followed by the HA container is that HACS is currently disabled as shown by the logs...

====================================================================

Config entry '' for hacs integration not ready yet: HacsDisabledReason.RESTORE; Retrying in background

12:01:00 PM – (WARNING) config_entries.py

HACS is disabled - HacsDisabledReason.RESTORE

12:00:59 PM – (ERROR) HACS (custom integration)

[Expecting value: line 1 column 1 (char 0)] Restore Failed!

12:00:59 PM – (CRITICAL) HACS (custom integration)

Could not parse JSON content: /config/.storage/hacs/172733314.hacs

12:00:59 PM – (ERROR) util/json.py

====================================================================

Does it matter, now that OCPP is installed?
Or does HACS have to be running all the time?

[martenjacobs]

@GrantKeymer I’m not sure if HACS needs to be running. I’d say probably not because HACS simply adds a custom component to Home Assistant, but I could be wrong. Probably one of the devs of this plugin will be better suited to answer that.
As for checking if the server is running, nmap is still not the correct tool. Like the other tools you tried, it only checks if there's anything listening on the port. The problem with that is that docker listens on that port so that it can pass any connections on to the container; it doesn't tell you anything is listening on that port inside the container. You can try the tool shown in this comment. That will tell you if there's actually a server listening on that port.

[drc38]

@martenjacobs Thanks very much for your reply. Great to hear you had no problems getting your Wallbox connected under HassOS. It seems like that will be my way forward. So far I've tried using HA Core, running under WSL in Windows and that was a nightmare to be honest. Seemingly simple things such as trying to upgrade the Python version completely broke my installation and I had to reinstall 3 times. Then when I finally got Python 3.9 installed, I could not get the virtual environment to activate, so was unable to run HA.

Therefore I tried the containerised version of HA running under Docker using WSL in Windows. Installation was certainly much easier, and if it wasn't for this comms issue I would pursue it further. My Pulsar Plus has behaved identically when running with HA Core or HA Container so that leads me to believe it's something to do with Windows getting in the way. That's a pity because it makes an ideal test bed for experimentation until I decide whether HA/OCPP is going to be useful with my charger or not.

I will study the docs on Netcat to find out how it works and see if that gives me any clues.

If I don't get anywhere, I will look at buying a suitable hardware platform for HassOS. I already have an Intel NUC running my weather station and video surveillance so I don't want to mess around with it. Also have an ASUS board running a VPN for video streaming so don't want to mess with that either. Maybe a Raspberry Pi or ODROID will be the best idea. Which hardware platform are you using?

I use docker for home assistant running on a Qnap, rather than using NAT I suggest using the host setup option.

[GrantKeymer]

@martenjacobs - Thanks so much for your patience Marten, I really appreciate it. After installing Weasel, it now looks like I'm getting somewhere...

The first time I open the socket I get this...

But only once. The next time I open the socket, I get this...

And the same again and again, until I restart the container, then I get the first reply again (but only once).

Does this help to shed some light on what is happening?

[GrantKeymer]

I use docker for home assistant running on a Qnap, rather than using NAT I suggest using the host setup option.
@drc38 - That sounds like a great idea as it would save the need to do port mapping. However, I found this in the Docker docs...

"The host networking driver only works on Linux hosts, and is not supported on Docker Desktop for Mac, Docker Desktop for Windows, or Docker EE for Windows Server"

I am using the Personal Tier of Docker running under WSL on Windows 10. I'm pretty sure it comes under the category of "Docker Desktop for Windows", therefore the "Host Networking Driver" won't work for me.

If I can be sure that HA/OCPP will do the job for me, I plan to buy a Raspberry Pi 4 and use HassOS as Marten has suggested. I just want to do some experimenting on Windows first, before taking the plunge. Thanks to Marten's help with Weasel, I have made some progress tonight. Now hopefully a solution can be found and I will get my charger talking to OCPP.

[GrantKeymer]

Hello again all,
Since my last post in this thread, I've taken the plunge and bought a Raspberry Pi 4, installed HassOS, HACS and the OCPP Repo/Integration. The hardware is great, HassOS runs as expected and HACS is running normally after waiting for the usual GIThub errors to clear.

However, the OCPP Integration doesn't seem to be doing anything. Below is a screenshot showing the Netstat results. There is nothing listening on Port 9000...

Using Weasel confirms this...

I have tried removing and reloading the Repo and the Integration. Server logs show the usual WARNINGS about Custom Integrations but all other entries are just INFO. I really don't know what else I can do to troubleshoot this. Any suggestions greatly appreciated.

[drc38]

Based on that my guess is websockets has not installed, you could try a manual install, checking folder location etc

[drc38]

Note websocket_api is not the same and is used by HA itself

[GrantKeymer]

OK, thanks, I'll give that a go. Meanwhile, this ERROR has appeared, but I'm not sure whether it's relevant to OCPP...

8:22:12 AM – (ERROR) components/hassio/http.py

[GrantKeymer]

Sorry DRC38, I'm going to have to ask you to guide me through the installation of Websockets, step by step. With HassOS, it seems that many of the Python commands I'm familiar with from my earlier installation on WSL don't work. For example, python --version isn't found, let alone PIP which presumably I would need to install Websockets?

[drc38]

Afraid I can't help as I've never used it, try the HA forums. @lbbrhzn may be more familiar with it.

[lbbrhzn]

The websockets package should be installed automatically, at least if you install through HACS.

[GrantKeymer]

@lbbrhzn - Yes, I did install through HACS. Then removed the OCPP Integration and Repo before reinstalling again, just to make sure I hadn't done anything wrong. This is happening each time...

2022-01-14 07:48:47 INFO (SyncWorker_5) [homeassistant.util.package] Attempting install of websockets>=10.0

And then no further mention of 'websockets' in the log. Does it mean that websockets is not installed?

[lbbrhzn]

@drc38 we currently have websocket listed in requirements.txt, and websockets in requirements_test.txt.
Could this explain the issue?

[drc38]

I doubt it those are only used for the testing environment. HA uses manifest.json to determine any dependencies.

[drc38]

Here's a log with the detail you should expect with debugging enabled: https://github.com/lbbrhzn/ocpp/files/7186245/home-assistant.1.log

[drc38]

Unlock is only applicable if you have a socket cable connection rather than tethered cable. Glad to hear you have comms to the unit. Did you change the manifest file or leave as is?

The exception is an upstream repo issue, a fix is being worked on.

[GrantKeymer]

When you connect an EV to the Wallbox Pulsar the status will become 'Preparing'. You then need to send it a 'RemoteStartTransaction' command, which will trigger the Wallbox to send a 'StartTransaction' request. When this is confirmed, it will start the charging session.

Yes, I can see 'Preparing' displayed now, after plugging in my EV.

The Unlock command can be used to force an unlock of the connector, terminating an ongoing charging session.

Thanks for explaining. I thought it unlocked the charger, turning Yellow LEDs to Green but see what you mean now.

I will copy your automation script in and see how it goes with 'RemoteStartTransaction' and 'StartTransaction'.

Thank you!

[GrantKeymer]

Unlock is only applicable if you have a socket cable connection rather than tethered cable. Glad to hear you have comms to the unit. Did you change the manifest file or leave as is?

I left the Manifest file as is. It just started working all by itself, about an hour after changing the IP address. I did try that before, but obviously didn't wait long enough. Now if I restart HA, the Wallbox app says 'OCPP connecting' for only a short time - less than a minute I think.

The exception is an upstream repo issue, a fix is being worked on.

Yes, I saw the comments about that in one of the Pull Requests. Something to do with Mobility House by the look of it.

Great work guys, I have plenty to tinker with now. Many thanks for all your help.

[lbbrhzn]

You might want to try downgrading the ocpp version in the manifest to 11.0 or 10.0 to work around the upstream issue

[GrantKeymer]

You might want to try downgrading the ocpp version in the manifest to 11.0 or 10.0 to work around the upstream issue

Thanks, I'll give it a try. I have your automation script installed but because of the upstream issue, it doesn't do a lot. Charger Reset button works perfectly, and Charger Heartbeat resets every hour but that's about all so far.

[GrantKeymer]

Just to close off this thread...

Repo v0.4.5, 0.4.7 or 0.4.8 all provide stable connections via OCPP. Each of them are now using OCPP Library v12.1 which has the 'Remove_Nones' bug fixed. For added stability it is recommended to make sure you're running Websockets 10.1 or later, rather than the earlier 9.x version which was bundled with HassOS 7.0. Special thanks to all involved for their hard work 👏

[andre-richter]

Did any of you guys see connectivity issues the recent weeks?

I got my Pulsar Plus now. It came with SW 5.3.20, and I upgraded it to 5.5.10.
In general I must say that Wifi connectivity on this thing is absolutely shocking so far. It loses connection round about every 10minutes, after which I have to reconnect through the App. It won’t fix itself over time.
It can’t be signal strength because it shows full bars in the app, and the Wallbox is only ~10 meters away from a repeater with a single brick wall in between.
Also, if I measure signal strength with the smartphone next to the Wallbox, I get more than 200 MBit on the 5Ghz band.

Anyways, during the brief periods where wifi works, I cannot get it to connect to the OCPP integration.

I am on home assistant 2022.3.5 and ocpp integration is 0.4.25. Weasel successfully connects, and I can also see it talking to HA on tcpdump.

From the Pulsar, however, not a single packet arrives on port 9000.
In the URL field of the Pulsar settings, I‘ve put the IP of the HA machine (without preceding ws://), so can’t be name resolution, and also I don’t have any firewalls running whatsoever.

Grateful for any hints ☹️

P.S.: The wifi connection loss issues seem to be not that frequent when OCPP is turned off. Not sure what to make of that, though.

[andre-richter]

Thanks for the hint!

I checked my Fritzbox (it's a 7590) logs again and found one error message where it said that some device (not the Wallbox) did not succeed reconnecting because of PMF.
The messages about the Wallbox just simply state:

1. Connected
2. Disconnected.

With 5 seconds time in between. No mention of PMF.

I think I'll still give WAP2 only with the 5.5.10 a try when I get a chance.

[drc38]

I take it you've got Log registrations and deregistrations and expanded Wi-Fi information checked under the wifi log? Such frequent disconnects are odd you may need to run wireshark or similar to see what's happening.

[andre-richter]

Yes, that box is checked 👍

What would I look for in Wireshark? It is for capturing packets, isn't it? How would they be tied to Wifi connection issues?

[drc38]

https://wiki.wireshark.org/CaptureSetup/WLAN

[andre-richter]

Oh, TIL, thanks a lot!