Enel X migrating from JuiceNet to JuicePass #86588
Comments
|
I have the same issue with Home Assistant. |
|
Confirmed. Same situation. Edit: The app is absolute garbage. 😆 |
|
Yeah I received an email notification from them saying they are shutting down the Juicenet portal and the Juicenet App which I assume meant the API that Home Assistant is using. I myself also do not use (or even have) a juicenet charger any more so I am not going to be of any use here.
|
|
Let's hope that a developer was using this integration and will be updating it to the new api #fingerscrossed |
|
I took a look using a SSL/MITM proxy and couldn't make much sense of the APIs used. They seem to issue POSTs with no response and then possibly receive (gRPC?) data over Google APIs, maybe a firebase offering. I can't see too much further as the SSL isn't transparent between Google Play Services and their servers. |
|
Having the same issue and the new app is terrible |
|
Spoke with support and they confirmed the API is going away and they have no plans in offering a similar product. I asked if they could submit a suggestion/request for one in the future |
|
I'm guessing no API doesn't mean no integration. Is there still hope for this? |
|
At this point, no. I hope enough customers request this feature so they see the demand and bring a new API online. |
|
Reached the support and sent a complaint for the API removal. |
|
My chat with support on Jan 30th: (09:37:31 PM) *** Spencer Simpson joined the chat *** Your devices not connecting to home.juice.net is normal, and the phantom device in your app is a common product of the migration. After JuiceBoxes are moved to the server, they cease all communications with the home.juice.net server, and we are still moving on a timeline of completely shuttering it from Feb. 20th on. We can resolve the phantom JuicePass box by removing the unit from your home.juice.net account, leaving only the entry for your JuicePass account. |
|
A decrease in the features will certainly affect customers experience, I contacted them to know if they plan on working on it since I primary bought it for that case and if they are offering a refund regarding this problem. |
|
We also lost the ability to manage load groups, so I complained about that and the API being unavailable. I was about to buy a 2nd charger and wire it to the same circuit. In the old system, it would limit the total amperage of the group to the rated amperage through software, and that isn't a feature in the new app... so fire risk, tripped breakers if you had that setup during the migration? yikes. |
I lost the ability to control charge current via juice pro but figured out a way to control it from Tesla. |
|
Got this today, so they don't seem to have their story straight but maybe there is hope.
|
|
I hope they re-enable this. The new app is garbage. |
|
We have a load group of 2 JB40 and still seem to be on the old system. Haven't received any migration email yet. I did copy source locally and hard code max amp value at 40. That value was not being fetched correctly and would error (unable to set, valid range 6-0). Didn't want to dig too deep and fix properly due to the unknown status of the API. |
|
If you have been impacted by this change, you can request support move you back to the old platform. It took a few weeks and requires a new token. It appears they know this migration has been a huge issue for their customers and they offered to move my system back. Not only did the new app/platform break the API, but it's TOU scheduling is broken, as well as load sharing capability doest not exist anymore either. |
|
I started a reverse-engineering effort of the new Enel X Way API and have put my findings in a public Gist. Help is very much welcome! So far I have the endpoints, but need to understand authentication, potentially request signing, etc. |
Looks promising, is there a way to request an API after the migration? |
Not that I know of. It’s all private. I don’t want to share their code, since it’s probably copyrighted, but what I did was download the app’s |
|
Any update on this one? I just got forced to the Enel X Way app and lost JuiceNet access including the mobile app, webapp, and HA integration. Happy to help contribute if I can. Wondering if there is any additional understanding of the auth component. I believe JuiceNet creds work for the Enel X app, so wondering if the JuiceNet tokens still work with Enel X. Enel X appears to have their own account system at my.enelx.com but the JuiceNet creds don't work there, and there's no apparent way to create an account. It would seem at first glance like the Enel X Way app is still using JuiceNet for auth, but I have not really looked at it all. Just at the point of realizing I got migrated and everything broke. |
|
I don't know if this is helpful, but port 2000 is open for telnet to the Gecko OS of the JuiceBox - I tried to expose the web server on the wlan interface, and reboot, but the Juicebox seems to reset it to the softap/default on reboot. Maybe someone more industrious can figure out a way to expose something useful? |
|
I played around with Gecko as well, but I don't think it's going to get you anywhere. The Gecko OS itself is only aware of the GPIO pins on the Gecko chip, what matters is the custom software that Enel is running under Gecko OS and how that's interacting with the GPIO pins and the data that it's sending up to the cloud. Even if you could reverse engineer that piece of software, I doubt you could run something on the Gecko system to monitor it. |
|
FWIW, I was told by Enel X support that I could no longer request to be switched back to JuiceNet once I switch to the new app. I decided to sell my charger, and get one that remains open for integrations, but soon found that in Enel X Way there is no longer a way to transfer ownership of a device. I wrote to support again and asked that they remove my ownership of the device so that I could resell it, at which point they were nice enough to move me back to JuiceNet.
So there is hope. I busted out a new automation that automatically sets the amperage of my charger based on the remaining charge of my Powerwall. Works great except that charge_now off does not seem to work. It toggles in HA, but does not actually turn off. Oh well. Glad to have this much of an integration working so that car charging does not burn through my battery overnight or on cloudy days. |
|
It looks like I've been moved automatically to the new platform. I never even installed their new app, the charger just started showing "unavailable" a few days ago. @cgraf I just got off the chat with support, and they told me they ended the contract with the provider for the old platform. I would assume they'll probably force everyone on the new platform in the next few weeks. This is very frustrating, as I bought that device specifically for the Home Assistant integration... I imagine I'm not the only one in that situation. |
|
I'm happy to test this if there is a straightforward and well-documented way to set this up as a HA add-on, which I'm not immediately seeing anywhere. |
|
Also happy to test, I have the proxy working via firewall rules to keep intercept traffic. |
|
Looks like I'm going to be jumping in here with full force soon as well. I haven't actually tried it out yet as I still find the challenge of redirecting UDP traffic a bit daunting. Any way I can help, I know most of the internals of the box. The challenge is that the ZAP-equipped boxes don't listen to the UDP parameters exposed by ZentriOS - the ZAP (Zentri APplication) does the communication on its own, and it has no reason to listen to ZOS parameters - it makes the UDP connection and sends the data on its own. A man-in-the-middle WiFi AP (something perhaps running DD-WRT or modern equivalent - a great use for an E-waste trash router?) may be the only way to have a device redirect the UDP traffic. If we can reliably clear that hurdle and have a setup guide for how a novice-skilled techie could set it up, across as many variations of JB firmware possible (ZAP and non-Zap - non-ZAP is easy!), then this could be a very awesome fill-in for the soon-to-be-dead Enel services. |
|
I agree and offer to help.
I have only the ZentriOS devices, including the first 3-phase JBs, and I have another product that used this WiFi too – plus the firmware for the up to 8.17 versions. Some of the original source code too (when it was open source) but I suspect too much has changed.
An ESP32 would make a good man-in-the-middle.
I have two running JB32 (22kW) that I migrated with difficulty to Enel X-Way. I see both are on-line. Originally, they migrated then to the Italian server, and they had to be brought back to the US (I am I NZ). All that effort wasted.
Anyway, I am on an electricity plan with 3 hours free power, so I think I just let them rip and forget control….just use the EV which is integrated already with HA.
From: Matt Falcon ***@***.***>
Reply to: home-assistant/core ***@***.***>
Date: Thursday, 3 October 2024 at 7:37 AM
To: home-assistant/core ***@***.***>
Cc: saltydog256 ***@***.***>, Comment ***@***.***>
Subject: Re: [home-assistant/core] Enel X migrating from JuiceNet to JuicePass (Issue #86588)
Looks like I'm going to be jumping in here with full force soon as well. I haven't actually tried it out yet as I still find the challenge of redirecting UDP traffic a bit daunting. Any way I can help, I know most of the internals of the box. The challenge is that the ZAP-equipped boxes don't listen to the UDP parameters exposed by ZentriOS - the ZAP (Zentri APplication) does the communication on its own, and it has no reason to listen to ZOS parameters - it makes the UDP connection and sends the data on its own. A man-in-the-middle WiFi AP (something perhaps running DD-WRT or modern equivalent - a great use for an E-waste trash router?) may be the only way to have a device redirect the UDP traffic.
If we can reliably clear that hurdle and have a setup guide for how a novice-skilled techie could set it up, across as many variations of JB firmware possible (ZAP and non-Zap - non-ZAP is easy!), then this could be a very awesome fill-in for the soon-to-be-dead Enel services.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Ooh, an ESP32 is ideal indeed. Or the cheapest ESP device that exists. Very simple task at heart - to redirect UDP traffic to another device. Can an ESP32 act as both a client (connect to another network) and a station (broadcast an AP) at the same time, offer DHCP to the attached device, spoof DNS, listen to the UDP traffic, and forward those packets on to the configured server on the client side (and vice versa)? If so, there's a well-paved path to getting this done super easily. I just have a soft spot for reusing old electronics ;) But most people will definitely choose the cheap ESP dongle route, I'm sure... |
|
Before they close down the app, I set the current to 40A and removed the
schedule. If we can't hack the unit, at least it can be a dumb charger. An
expensive dumb charger. I bought this because of the HA integration
originally 2 years ago.
I'm running the proxy currently and am willing to open my unit and do a
brain transplant to some ESP32 goodness, if that's what it takes to take
back ownership.
Looking forward to what this community comes up with!
…On Wed, Oct 2, 2024, 5:29 PM Matt Falcon ***@***.***> wrote:
Ooh, an ESP32 is ideal indeed. Or the cheapest ESP device that exists.
Very simple task at heart - to redirect UDP traffic to another device. Can
an ESP32 act as both a client (connect to another network) and a station
(broadcast an AP) at the same time, offer DHCP to the attached device, and
spoof DNS? If so, there's a well-paved path to getting this done super
easily. I just have a soft spot for reusing old electronics ;) But most
people will definitely choose the cheap ESP dongle route, I'm sure...
—
Reply to this email directly, view it on GitHub
<#86588 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAHJZP3BYAQVX2DPU3BVTA3ZZRQUPAVCNFSM6AAAAAAUFWZFK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOBZG4ZDOOBQHA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Oh no! I don't mean replacing anything with an ESP32 (the WiFi chip is soldered anyway), but rather, designing something (using an ESP) that would just plug into a USB port around the house like a WiFi extender or Zigbee dongle. Much like smart-home bulbs and switches use a "hub". And then you'd simply configure the JuiceBox to connect to the dongle's network (running through WiFi setup, which doesn't need their silly app), and you're home free - the dongle would redirect traffic to your HA and give you complete local control, monitoring/metering, etc., all with the existing power/capability of Home Assistant. I actually get warm fuzzy just thinking about that idea. I really want to see it become a reality - it's very user-friendly and maintainable, I think! |
|
What are the chips in it? Maybe we could get openevse software ported to it |
|
Basically an Arduino.
From: beren12 ***@***.***>
Reply to: home-assistant/core ***@***.***>
Date: Thursday, 3 October 2024 at 11:57 AM
To: home-assistant/core ***@***.***>
Cc: saltydog256 ***@***.***>, Comment ***@***.***>
Subject: Re: [home-assistant/core] Enel X migrating from JuiceNet to JuicePass (Issue #86588)
What are the chips in it? Maybe we could get openevse software ported to it
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
|
Core processor is an ATmega328p - literally an Arduino and the same as OpenEVSE. Core processor handles the entire system's operation, including LEDs, relay control, GFCI, metering, ground monitor, protocol processing, everything. This is applicable to the black metal box JB1.x (3 front LEDs), PCBs v8.14.x to 8.17.x. Prior models used AMW006 (8.12.4 or so), or AMW004 (8.12.2 and prior). The super special Kickstarter-era box used a Roving Networks WiFly, which pre-dated any semblance of modern IoT and ... God help anyone that still has one of those (all long dead because they're so hard to configure). The plastic-and-purple Enel JB2.x boxes used the same ATmega328p as a core processor, but changed the metering chip to a 3-phase model (M90E32 or *36, not sure), and a new SiLabs-branded Zentri module for WiFi. In that case, some system control moved to the WiFi chip - like the front panel LEDs and metering. Thus, the meter IC actually talks to the WiFi chip, making the two an inseparable mesh (box will run at 12 amps - 120v default - if the WiFi chip stops responding). |
|
Thanks Matt, you had previously saved our juicebox with a replacement relay and LED strip, and now you are saving it again. Watching this thread with great interest. Cheers! |
@FalconFour the older devices does not support the telnet method to set the server address ? For all users that have devices that support the telnet I dont see a reason to use separate ESP device, just use correct configuration on juicepassproxy and it will configure the juicebox to send the commands to the juicepassproxy. Making a new device to be a gateway is really the easiest path ? without the enel x app, maybe a set os well documented scripts can also be used to configure a factory state device to use the juicepassproxy and the correct wifi network. |
|
@ivanfmartinez The NEWER devices - anything after 2016-ish - use ZAP firmware. ZAP has no reason to listen to "the telnet method", because Telnet only interacts with ZentriOS parameters. ZAP doesn't use those, it makes its own independent decisions as to what server to connect to. It first defaults to a switchboard server (capable of redirecting legacy devices), and it also goes and asks the directory server for which server to connect directly to. Once it gets that info, it switches to using that server for UDP traffic. At no point does the ZAP ever check or use the "udp" variable used in the Zentri console. It's always blank because the "udp" variables apply to ZentriOS' core UDP client functionality - which isn't what ZAP is using. I'd give a generous guess that up to 20% of stations are running non-ZAP software, that is capable of using that UDP parameter from Telnet. All the other 80%+, couldn't care less what you set that to. Curious if wrong, definitely something to test (e.g. if there's a hook in the firmware that "if this parameter is non-blank, it takes precedence" for debugging?). Edit to add: I'm just straight-up wrong about the approach I thought it was taking. It's actually closing and re-opening the stream from under the ZAP! Literally pulling an "Indiana Jones" on the stream handle. I kinda love it. It's unreliable because the ZAP unpredictably decides to reopen the connection (to the destination it chooses), but it does work, and that's a great starting point. |
|
From what I recall of my original experimenting I was able to see where it was connecting from the telnet interface I could close that connection and open a new one with the same number and it would continue to use it to send data, but only for a minute or 2 before it reset back to its original location. It also seemed to be a little hit or miss timing-wise to open a new connection without it noticing and I always lost a packet or so while doing it, which is why I ended up with the firewall redirecting method instead. What I don't recall is whether I tried switching this way from the telnet interface after I was redirecting the valid server responses back or not, it's possible that it might not switch back to the enelx.com server as quickly if it gets valid data back. |
|
Yep, this is definitely worth digging into more. I feel bad that I still haven't set-up JPP proper myself, because the act of getting it into HA is a bit daunting (plus, day job etc...). But now that I have bench-tested it myself and proven it works, it changes things a bit. The reliable way is still a man-in-the-middle device to spoof the DNS and make it always believe it's talking to "jbv1.emotorwerks.com:8042" (and block access to the directory server, so it never gets redirected to "*.enelx.com")). That directory server is "directory-api.emotorwerks.com" - block it, and it should always try going to "jbv1.emotorwerks.com:8042". The info from the directory server is never stored persistently - it learns it on every startup. More to come soon, for sure. |
|
Okay, I just went ahead and tried it. Looks like it still switches back. Took 2.5 minutes that time. I continued to get good data in HA during the time that it was connected directly to the local JPP. It does seem like in theory you could use the telnet interface to do the same thing every time it changed back and get local control without any traffic redirecting, but you'd be fighting it the whole time so not sure how reliable it would be. On the other hand it wouldn't require any extra hardware or router/firewall changes so the setup could be easier. |
|
For reference I'm using juicepassproxy without enel x servers for a few months. The solution probably is not applicable to any router, but what I made in my mikrotik was to redirect ANY UDP traffic that came from juicebox to my juicepassproxy instance. No changes on DNS. This is the option C on the juicepassproxy instructions : https://github.com/snicker/juicepassproxy?tab=readme-ov-file#docker-compose-installation Maybe if enel x removes the DNS entries I will need to create DNS entries in my router, but for this months I just redirected the UDP packets. |
|
Nice solution Ivan, thanks for sharing. My router can do that as I am doing that with a Solar Inverter for HA.
I have a command somewhere in the archive that using an FTDI to change where the URL JuiceBox send UDP traffic too. That might be easier for some – it’s one command line. I had to do that when Enel took over eMotorwerks (I hand built the first opensource JuiceBox in 2015). It’s in my “History Box and probably still works.
From: "Ivan F. Martinez" ***@***.***>
Reply to: home-assistant/core ***@***.***>
Date: Friday, 4 October 2024 at 7:30 AM
To: home-assistant/core ***@***.***>
Cc: saltydog256 ***@***.***>, Comment ***@***.***>
Subject: Re: [home-assistant/core] Enel X migrating from JuiceNet to JuicePass (Issue #86588)
For reference I'm using juicepassproxy without enel x servers for a few months. The solution probably is not applicable to any router, but what I made in my mikrotik was to redirect ANY UDP traffic that came from juicebox to my juicepassproxy instance.
No changes on DNS.
This is the option C on the juicepassproxy instructions : https://github.com/snicker/juicepassproxy?tab=readme-ov-file#docker-compose-installation
Maybe if enel x removes the DNS entries I will need to create DNS entries in my router, but for this months I just redirected the UDP packets.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: ***@***.***>
|
That's "udp.client.remote_host" in ZentriOS, used on boxes that aren't running ZAP. Your box is probably quite old, then :) If that is the case, indeed you can just change the host to your local server, clap the dust off your hands, and you're done forever! It'll just work like that forever. That, however, is the base of the reasoning I thought we were further away from a solution than we really were. I didn't think we could "Indiana Jones" the stream handle like that through Telnet. Very cool trick. I had thought Telnet was changing the host as you describe, and that parameter probably applies to only 20% or less of remaining JuiceBoxes still not using the ZAP software (which was fed to older boxes through the app-based Setup process). All JB2.x and most "3 front LED" black boxes (JB1.x UL) use the ZAP software, thus my surprise to see the Telnet technique actually works. Just need to find the cadence/pattern at which the software re-starts the UDP connection... maybe it'll stop resetting the connection if we simply send responses to each message (as JuiceNet did). I know it's got a watchdog looking for those for connectivity verification... |
|
Has anyone done the C. Option here https://github.com/JuiceRescue/juicepassproxy?tab=readme-ov-file#getting-enelx-server-ips with the new Unifi/Ubiquity Masq/Destination Rules? |
I tried, but haven't succeeded yet. If anyone has, and can do a quick run down on how to do it from a Unifi perspective, it'll be greatly appreciated :D. |
|
I lost access to the web site back in Feb and have been using proxypass for the past 3 months on HA. As this is a DOCKER setup I have no access to the code but did the install via a wrapper. I then changed my UDP on the device to point to the HA IP address. Data is now flowing, I have no control yet just collecting data so I know how much Juice I have pumped into the car.
0 UDPC 192.168.20.5:8047 (30000) |
|
Just got this in my inbox a few minutes ago
|
|
This issue should really be renamed, since it doesn't really begin to capture what's been happening in recent months. For anyone interested in local control of their JuiceBox, there's a much more elaborate operation happening over at Juice Rescue. Very active Discord too. |
|
Will,
Agreed, it seemed the best place to share the update, since I didn't know
about Juice Rescue.
Thanks.
…On Thu, Oct 10, 2024 at 6:37 PM Will Adler ***@***.***> wrote:
This issue should really be renamed, since it doesn't really begin to
capture what's been happening in recent months.
For anyone interested in local control of their JuiceBox, there's a much
more elaborate operation happening over at Juice Rescue
<https://github.com/JuiceRescue/>. Very active Discord too.
—
Reply to this email directly, view it on GitHub
<#86588 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAX7Q2ZBZTWS2ZWBRPFGKPLZ24TU3AVCNFSM6AAAAAAUFWZFK2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMBWGM3DKOJYGM>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
Closing this issue as JuiceBox servers seem to be going away. Other issues/projects are addressing getting direct access to residential JuiceBox EVSE. |
and others
The problem
Enel X is migrating from JuiceNet to JuicePass.
Received email stating:
since migrating my account, the JuiceNet app shows “disconnected” while their new app JuicePass shows the current data.
Is there a plan to update the Home Assistant core JuiceNet integration to work with JuicePass?
What version of Home Assistant Core has the issue?
2022.12.5
What was the last working version of Home Assistant Core?
2022.12.5
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
The text was updated successfully, but these errors were encountered: