-
-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topdon EVSE continuously reboots #1203
Comments
I just bought one of these after reading the Home Assistant mention in the guy's review. I did NOT get the 123456789 password to work, so I am at a loss. Did you get that far ? |
Yeah it's 1-8 not 1-9. Make sure you write down all the info in it before you change anything (serial number, factory OCPP url, etc) because resetting the unit does not restore the original values |
Also FWIW, the problems the grizzl-e charger have looked similar so I tried the work around that's supposed to make those work but it made no difference |
Just adding my experience with this charger and this issue, I bought and configured a MaxpeedingRods charger last August and configured it to work with this OCPP integration. It worked well, and provided me with the 3 key features I was looking for: HA control to start/stop the charge, current control during the charge, and tracking the power used daily. I'm 100% solar at home and need to manage the big power loads timing. This worked fantastically until 0.5.2 when this behavior started where it will communicate for around 20sec, then lose connection, then reconnect about 30sec later, where the integration reports a charger reboot. The charger has not, however, rebooted (unless it magically reboots without stopping the current charge cycle :). Like I said, it worked fine until 0.5.2. I suspect it is some kind of Websockets timing issue or something similar, and I have tried many adjustments to the configuration options related to timing (WEBSOCKET_CLOSE_TIMEOUT, WEBSOCKET_PING_TRIES, WEBSOCKET_PING_INTERVAL, WEBSOCKET_PING_TIMEOUT, SLEEP_TIME, etc.) but no changes to those values seems to have any effect on the behavior. Sadly, I don't know more, I am hoping that a future update will bring a fix! I will certainly post back here though if I have any relevant info/experience. |
Here is my experience with getting to the configuration of the MaxpeedingRods charger, this is after a couple of days of trial and error back last summer: When the charger first starts up, you will have a window of opportunity to create a connection to the chargers internal wifi that will broadcast a name something like EVSE-XXXXXXXXX or TAPDON-XXXXXXX. I used a tablet or a smartphone sitting next to the charger outside. Once connected through wifi directly from your phone/tablet, etc. you open a webpage to the IP number of the charger (in my case it was 192.168.4.1). This will bring up the login to the firmware on the charger, and I will say that in my experience once I put in the password (defaulted to 12345678), I had to click the button on the webpage to login successfully. If I hit enter on my tablet/phone, it errored out. Once in the firmware, I could then change the settings, including the login password and once done, I could save, and then reset the charger. Each time the charger is powered off/rebooted, you will have this window of opportunity to connect to the internal wifi of the charger to make changes. But if there is a configuration setting you've entered for the connection of the charger to your home wifi, once the charger connects properly, you won't be able to login to the charger. In my case the charger internal wifi broadcast will go away until I reboot the charger. Hope this helps |
Thank you, i will try downloading 0.5.1 and see what happens. Is that still the version you're running? If so, is it still working correctly? |
Sadly, that did not work for me, I tried removing/installing about 3 or 4 versions back prior to 0.5.2 but saw the same behavior each time. I would be curious if that is the case with your setup too. if you go back to 0.5.1. I'm wondering if there is some other related code that updated around that time that is the real culprit here, like a python update, etc., but just not sure. :( But no, I reinstalled the latest version available (0.5.7), but currently have my entities (central and charger) removed. The alert messages were seriously messing with my OCD! :) |
Same for me, 0.5.1 made no difference. Sad trombone. Just did a quick test on my lunch break, didn't have time to do much digging |
Thanks bkcberry for the result info. Sometime in the next few days, I am going to try to see if I can tell if I can setup a virtual central server and connect the TapdonMaxpeedingRods charger to it to see if I can see any basic errors with communications. The ocpp addin is based on python code from mobilityhouse (https://github.com/mobilityhouse/ocpp). I am not a python expert or anything close to it (!) but I can will setup a test environment to a test "central" server. I will post anything relevant back here. |
I got it working! I downloaded and extracted 0.5.0 and needed to manually install the packages and their respective versions that are listed in requirements.txt for 0.5.0 |
That is awesome to hear! I will do the same first thing in the morning and try to replicate your success! Thanks for posting, at least I know it’s possible :) btw, I did get a virtual machine setup with the base python test central server and got my charger to connect. It connects fine, although it gives an error about a couple of unknown messages from the charger, but it stays connected. I’m going to set that aside and try the 0.5.0 route in HA. Thx again |
This is a big ask, because I'm pretty ignorant with the way different installs of HA work, for example I can use the Terminal addon to get to my configuration, but things like pip, etc. are not available. How did you get those packages set to the correct versions? I see the list of packages/versions in the requirements.txt. I suspect that one of those package updates is what is really behind the issue (jsonschema==4.19.2, or maybe websockets==12.0), but I don't know how to update/revert the versions of them. Like I said, that is a big ask because of my ignorance, feel free to say "bruh, go get edumacated" :) |
No worries. I run home assistant in a venv (python virtual environment) on ubuntu, it's the instructions on this page towards the bottom for "Install Home Assistant Core." I have actually set up a 2nd instance of HA just for testing this addon, and since it requires old packages I may just leave it there with OCPP being the only thing it does. Anyway, follow the instructions on how to install the Core version of HA, but instead of
you would run
From there you would also need to extract the contents of v0.5.0 to ha_config_folder/custom_components/ocpp
I hope that helps, this is the only way I know of to get this old stuff installed. I couldn't figure out how to manually install old packages in docker (it seems like you'd need to make your own custom image), and I have no idea how you'd do it on any of the other ways that HA can be installed. I use node-red pretty extensively, so I'm thinking I may use that to feed data from my "ocpp" instance of HA over to the main one via input helpers. Not really sure about that yet |
Thank you so much for the info. I will have to wait a day or too to dig into this, but I think I understand. If I get any other info, or workarounds discovered, I will post back here. |
Hi all, sorry if I am hijacking this thread but I am also trying to setup the TOPDON charger with this integration. Are there any special steps to get this working? I followed the standard guide and updated the TOPDON configuration to point to Does plug and play need to be "No" or leave that as is? Any other configuration that needs to be updated? I know it's using the OCPP1.6-J protocol, didn't touch that. Left the "AuthPass" as is as well. I get no connection on the home assistance logs though. I set the websockets.server to debug and it only shows the entry for starting the listener. For the ocpp logs I only see the entry for Full log if it's helpful:
Thanks in advance! |
Scratch that, I had a silly typo in the IP Address. So now I actually just have the same issue described here where it loops in the connectivity. Will attempt the same downgrade of versions and see if it resolves. Thanks @bkcberry for posting your solutions! |
Does this mean that we need to switch back to all old version of home assistant and never upgrade, or is it just some small files that need to be reverted and held?
Get BlueMail for Android
…On Jun 15, 2024, 6:54 PM, at 6:54 PM, onelight17 ***@***.***> wrote:
Scratch that, I had a silly typo in the IP Address.
So now I actually just have the same issue described here where it
loops in the connectivity. Will attempt the same downgrade of versions
and see if it resolves. Thanks @bkcberry for posting your solutions!
--
Reply to this email directly or view it on GitHub:
#1203 (comment)
You are receiving this because you are subscribed to this thread.
Message ID: ***@***.***>
|
I'm not sure, as I said I set up a test environment for this and I believe it was on 2023.12.1, but in the process of installing the packages that are required for v0.5.0 of this addon home assistant got rolled back to 2023.11.1. It may work with something later than that but it also may not. My plan is to just leave OCPP set up on my 2nd instance going forward but that is mostly because it's working now and I'm tired of messing with it |
Just putting this here if the HA OCPP integration devs are reading this issue post. I found this from back in 2020. This is from the MobilityHouse git, which I think this integration is based on. There was an issue early on that presents specifically like this possible reoccurrence with the diconnects/reboot message every 40sec: |
For others who may stumble upon this and like me use the docker configuration. The steps are almost the same as the one posted above by @bkcberry Just pull the container for home assistant for version 2023.11.1 and then manually extract v0.5.0 of this custom_component "ocpp" and the run the same pip commands
All done inside the container. That worked for me and no longer getting the disconnect loop. |
Just an FYI after the 0.5.8 release. In 0.5.7, it would accept and connect to the charger and actually allow you to send commands (begin or stop charge, change available current, etc) for about 10 seconds before going dead. Then after the 40 second timeout and reboot signal, you could get control for about 10 seconds again. |
Stale issue message |
Version of the custom_component
0.5.6
Configuration
Not sure what to put here? I left most settings as default and checked skip schema validation
Describe the bug
When pointed towards home assistant/ocpp, the evse will repeatedly connect for a few seconds before rebooting. I did see where someone on amazon who bought this same EVSE was apparently able to get it working with this same addin/repo, and issue #1023 claims that what looks to be the same EVSE from amazon with different branding works as well
Debug log
The text was updated successfully, but these errors were encountered: