first version that can control current locally without enelx servers

[ivanfmartinez]

Not for merging now, but others can start testing to see and give feedback

Updated text on 2024-10 after many changes :

• It works for setting maximum current to be used on my device which used version 09u

  • we need to see on other versions if the size of command is correct
  • @FalconFour indicated that v07 accept the commands

• Putting 0 in Max Current (Online/Wanted) current_max_online_set parameter pauses the charging

  • when the charging is paused the device reset the session energy value
  • if juicebox lost connection with server (or proxy when acting as server) it will cancel the pause and return charging

• devices that uses v07 protocol does not send the configured offline current used

  • you can set current_max_offline_set_initial_state to the wanted stated at startup
  • if you dont set the value the JPP with try to :
    • use current_rating after few minutes or if you reboot the juicebox device it will get the first value received for current_max_online
  • you you change the values using MQTT it is not persisted to the configuration file

• The base message code comes from https://github.com/philipkocanda/juicebox-protocol

• There are more information about commands on start/stop mqtt button/switch #39

• Maybe the changing can fail if the command is sent when a message arrive from the juicebox overriding the value

  • some synchronization can be made for this case

• Docker images from this branch are available at :

  • https://hub.docker.com/repository/docker/ivanfm/juicepassproxy/tags
    • can be referenced as ivanfm/juicepassproxy:latest
  • @niharmehta has muti-arch container (arm/x86) with latest commits:
    • docker pull ghcr.io/niharmehta/juicepassproxy:latest
    • can be referenced as ghcr.io/niharmehta/juicepassproxy:latest

• The setup with this changes is running well for around 4 months

• Information in Portuguese about how I use this and homeassistant to control charging based on Solar production :

  • https://www.forumve.com/forum/viewtopic.php?p=3850#p3850

• If you have old entities from old juicepassproxy and want to remove the easiest path in home assistant is to DELETE de Juicebox DEVICE (not the individual entities), restart the juicepassproxy and all entities will be recreated

• My setup is based on :

  • my juicebox device was connected to the home wifi
  • all UDP connections that the juicebox try to do are redirected to my juicepassproxy instance using option C : https://github.com/JuiceRescue/juicepassproxy?tab=readme-ov-file#instructions
  • my router blocks all traffic from juicebox to internet
  • the juicebox can use my local services like DNS, NTP etc..
  • at this moment no DNS spoofing or other things

[ivanfmartinez]

Working to control the charging current based on solar power availability

[ivanfmartinez]

Sample HA automation to Pause/Start charging, working fine in my environment, in my case I resume with 12 amps and other automation that controls current by solar will take place to control.

In my case the minumum value must be 11 because the Bolt use a different behaviour when thinks that are connected to a portable chager when value is 10 or lower.

I dont know if this kind of sample can go on README or we must have a different file for information about this.

alias: EVSE - Enable / Pause Charging by schedule
description: ""
trigger:
  - platform: state
    entity_id:
      - schedule.horario_carregamento_evse
condition: []
action:
  - choose:
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: schedule.horario_carregamento_evse
                state: "on"
              - condition: numeric_state
                entity_id: number.juicebox_max_charging_current
                below: "1"
        sequence:
          - service: number.set_value
            metadata: {}
            data:
              value: "12"
            target:
              entity_id: number.juicebox_max_charging_current
      - conditions:
          - condition: and
            conditions:
              - condition: state
                entity_id: schedule.horario_carregamento_evse
                state: "off"
              - condition: numeric_state
                entity_id: number.juicebox_max_charging_current
                above: 1
        sequence:
          - service: number.set_value
            metadata: {}
            data:
              value: "0"
            target:
              entity_id: number.juicebox_max_charging_current
mode: single

[ivanfmartinez]

Energy session reset on pause

[markgergely]

do you have a docker tag with these changes? id love to test this as i have a similar usecase to yours

[ivanfmartinez]

@markgergely

do you have a docker tag with these changes? id love to test this as i have a similar usecase to yours

I dont have the environment to build and publish this docker containers, I'm just using -volumes on my docker-compose to override the files.

Maybe @Snuffy2 can create a tag like the async branch.

Here is my docker-compose.override.yaml file

services:
  juicepassproxy_tst:
    volumes:
      - ./tests/juicepassproxy.py:/juicepassproxy/juicepassproxy.py:ro
      - ./tests/juicebox_mqtthandler.py:/juicepassproxy/juicebox_mqtthandler.py
      - ./tests/juicebox_checksum.py:/juicepassproxy/juicebox_checksum.py
      - ./tests/juicebox_exceptions.py:/juicepassproxy/juicebox_exceptions.py
      - ./tests/juicebox_message.py:/juicepassproxy/juicebox_message.py
      - ./tests/juicebox_mitm.py:/juicepassproxy/juicebox_mitm.py

[Snuffy2]

Sure, I can get it into an alternate docker tag. Is it to a point where it is ready for others who are interested to start testing it?

[Snuffy2]

image: ghcr.io/snicker/juicepassproxy:juicebox_commands

[markgergely]

thanks for the quick turnaround, I am already running it, will report back

[ivanfmartinez]

Sure, I can get it into an alternate docker tag. Is it to a point where it is ready for others who are interested to start testing it?

It's working fine in my environment very stable.
Sure others can test, but we need to decide if I went to correct direction.

After more people test, with more firmware versions, we will know if the JuiceboxMessage class works for other versions and that code can be used to replace the current parsing of messages.

[tebrown]

Since EnelX is discontinuing North America Operations (https://www.juiceboxnorthamerica.com/), will this be the solution going forward? What are the chances that EnelX will open up their local API?

[ivanfmartinez]

Since EnelX is discontinuing North America Operations (https://www.juiceboxnorthamerica.com/), will this be the solution going forward? What are the chances that EnelX will open up their local API?

I did not remeber seeing a local API, just the protocol which the device communicates with servers.

If they at least publish all details about this protocol we can improve this implementation.

For me at least this is working fine for months, I can control the current of charging, pause from homeassistant without problems.

[tebrown]

Yeah, but they are shutting the servers down, which annoys the heck out of me :(

[FalconFour]

You're not going to see any local API, because the system wasn't really developed to any common standards. It was a hack job built by folks (guiltily raises hand) that didn't know what the hell they were doing, so they did what was easy to implement with the tools at the time. Initially, that was a Roving Networks WiFly module that had a UDP client system, that could blast any serial traffic out as UDP packets. It was all downhill from there - even long after the Roving module was gone and dead (it was very short-lived in favor of ACKme, later known as Zentri, later bought by SiLabs). The idea of "IoT" just wasn't established at the time.

Thus, the protocol that JuiceBox uses to communicate, and the style of its communication, is rather unconventional. It makes this a particular challenge.

The closest idea I have is to use a man-in-the-middle ESP(-32 or cheaper) as a "hub" for JuiceBox(s), much like smart-home bulbs and switches use hubs. It can act as an invisible WiFi AP that the box can be configured to connect to, it'll spoof the DNS for the box to connect to itself, and it'll happily stream data to the local server of your choice. It's the missing piece to this puzzle, I think.

I had more comments here, where I only recently realized wasn't part of the JuicePassProxy issues: home-assistant/core#86588 (comment)

Definitely going to be putting in whatever effort I can contribute to get this going, as I already use HA and am actually a bit excited to see this new era of community-built solutions for the JuiceBox to live on. I hope we can get the word spread and get more people using this and involved in it, having a more reliable and functional system, and not replace their boxes just because the app went dead! Lots of hardware can be saved right now, in this moment, with the right action...

[wguerlich]

Hi Matt, this idea of using an ESP32 in the middle sounds fantastic to me. Having done a few ESP projects this seems like a feasible task.
As the typical ESP32 modules can be flashed and configured directly through the web browser (Chrome+Edge) just as the ESPHome project does, that will lower the barrier for the casual user.

But what would be the ideal interface between HA and the ESP? ...so that it can run as a regular HA addon, without need for a docker container? Would that be a direct socket connection or MQTT?
To me MQTT seems like a natural fit, as it already provides some basic authentication and would make it easy to connect chargers from remote sites.

What do you think? Can we come up with a simple spec here of everything the ESP needs to do?

[carrel-gr]

Just adding a "datapoint" on the newly added power_factor...
When I am not charging, I mostly see no power_factor reported, but I also sometimes see 0.005 and 0.07 and some other "small" values reported. At midnight, my automation set the "Max Current (Online/Wanted)" to 40 and the car started charging. Power_factor went to 1.0 and stayed there until the vehicle was charged. Then power_factor dropped to the "small" values and unreported values again. That's with the Polestar. Will try with the Hyundai too.

[ivanfmartinez]

@carrel-gr the device does not send some of the parameters when not charging, current is one of then, but when not charging we can set the current as ZERO, others like this power_factor we don't have a way to set a value.

I see almost same behaviuour that you indicated.

[carrel-gr]

Just another datapoint... With the Hyundai, the behavior is similar. Power_factor went to .99 and .98 while it was charging, then it stopped reporting.

My simple (on at midnight, off at 3pm) HA automation is working great. HA now has full control of my JB and Enelx has been removed from the picture. Thanks again.

[lalley2ka]

Not sure why or exactly when it happened, but my "Act as Server" switches vanished from my HA MQTT integration. They were there earlier on my two chargers, and I haven't changed any configuration. Inspection with MQTT Explorer shows that there is no configuration topic for them.

Having said that, everything is working perfectly without them. I can control everything that is controllable no problem. I am running a pull from today (November 15, 2024).

Did I miss something? Is the switch not used anymore?

[ivanfmartinez]

@lalley2ka the switch is disabled in HA by default( have to be enabled to be controlled on HA), but have ON state as default

I had before cases of HA removing things that I have enabled on other devices (not in JPP).

https://github.com/JuiceRescue/juicepassproxy/pull/69/files#diff-f0b56a62fb82577d98349d94af41e58b863885d740fcac8eb3b680bbe8a36e08R392

[lalley2ka]

@ivanfmartinez , thanks for the reply above. I think it is possible though that the problem is with JPP, not HA. See my attached screenshot showing that there is no configuration topic published for the Act as Server switch in the broker (look at switches near the bottom left of the shot -- the switch for "Porshe" is something else, not related). Configuration topics for all the other stuff like the sensors and other controls are there, as they should be.

See also my shot from the HA MQTT integration complaining that the integration is no longer providing the switch (it used to).

As you point out, this is of low urgency, since the switch functionally defaults to "ON" anyway. I just thought it strange that it disappeared after I did a recent pull. Unfortunately, I can't pinpoint the date. Thanks again for everything! It is working great for me, and saved my JuiceBoxes!

[ivanfmartinez]

@lalley2ka I found the problem, its related with the merge to main branch which includes #76 to solve #74 this make it incompatible with the code in this branch. Now the switch should appear on your HA

[lalley2ka]

@ivanfmartinez , that fixed it! Thanks again!

[lalley2ka]

Does anyone know what these are? I get maybe one or two per hour:

2024-12-21 00:06:08 INFO [juicebox_message] from_string 0910042001260563987022629434:DBG,ERR:a acq err:
2024-12-21 00:06:08 INFO [ha_mqtt_discoverable.sensors] Setting Last Debug Message to ERROR: DirSvc acq err using hmd/sensor/JuiceBox_Left_Bay/Last-Debug-Message/state

Do I have a configuration wrong or something? Doesn't seem to cause any trouble that I have noticed.

[ivanfmartinez]

@lalley2ka "DirSvc acq err" appear to be ok for a device that does not have internet access, the device apparently is just indicating that cannot communicate with Directory Server.