Replies: 6 comments 4 replies
|
Hi @storacm — use the Wallbox as the plug signal, not ENODE. ENODE is cloud/EV-side and (as you found) only reports "plugged" during DC sessions, whereas the Wallbox knows the cable state locally. Point SEM's Connected sensor at the Wallbox's own status entity (e.g. Two things to avoid: don't leave it blank (SEM reads that as "no car" and won't start a surplus/solar session), and don't fake a permanently-on sensor (SEM would then never see an unplug or a finished session, and would keep planning night charges for a car that's gone). One quick check — in Developer Tools → States, look at the Wallbox status while the cable is in but idle; if it shows a value SEM doesn't map (e.g. "Waiting for car demand"), make a small template FYI: once current is actually flowing, SEM already overrides a lying plug sensor via its physics defence — but that only rescues an in-progress charge, it can't kick off the first start, which is why a truthful Wallbox-side signal matters. |
|
Hi @traktore-org , thank you so much for your reply. Great peace of work you put together, but quite complicated to fully understand how all interacts and connects. Greatful for your support |
|
Short answer: use the Wallbox's plug signal, not the car's — and please don't leave the field blank or fake an always-on signal. Both of those will bite you. Why ENODE is the wrong source hereENODE reports what the car says about charging. Your Wallbox Commander 2 is the thing the cable is actually plugged into, and it knows the difference between "no car" and "car present, not drawing". That distinction is the whole basis of SEM's decisions: solar-surplus charging means the car is there and waiting, which the car itself often cannot tell you while it is asleep. What to configureSEM auto-detects Wallbox and looks for these, in order: If your Wallbox integration gives you a plug/connected binary sensor, point SEM's Connection field at it and you are done. If it only gives you the status string ( For the plug signal specifically, a three-line template turns the same string into a binary sensor: template:
- binary_sensor:
- name: "Wallbox plugged in"
device_class: plug
state: >
{{ states('sensor.wallbox_YOURBOX_status_description')
not in ['Disconnected', 'No car connected', 'Error', 'Unknown',
'unavailable', 'unknown'] }}Check your own sensor's values in Developer Tools → States first and adjust that list — the point is "anything that is not no cable counts as plugged". The two things not to doDo not leave the connection field blank. SEM reads an unconfigured connection sensor as not connected ( Do not wire a permanently-on plug signal. SEM would believe a car is present around the clock: night charging would run against an empty bay, session energy and daily targets would accumulate against nothing, and the "car is full" detection would have no honest signal to work from. It trades one wrong answer for a noisier one. Your XPENG via ENODE is still worth havingKeep it — just for a different job. If ENODE exposes the car's state of charge, point SEM's Vehicle SOC field at it and you can charge to a target percentage rather than a kWh amount, with SEM working out how much is still needed. That is what the car-side integration is genuinely good for; the wallbox owns "is the cable in". If you paste the entity list your Wallbox integration created (Settings → Devices & Services → Wallbox → entities), I will tell you exactly which one goes in which field. |
|
Hi, As far as I can see it can have the following statuses: Another anoying thing about the Wallbox Commander 2 is that you have to unlock to charge which, is another sesnor than the pause/resume sensor. If the unit is not unlocked first, you can not use the pause/resume button, as it is unavailable. Another question sabout SEM, how does it determine what is cheap? My Wallboc Commander charger is also connected to a power meeter for the complete hous via modbus and the wallbox commander optimises power usage based on avaialable power. Does this work together with you shedding an ramping etc? Thanks again for your support. |
|
Hi again, here is a list of all the entities from the Wallbox Commander 2 charger: Depot price |
|
Thanks for the entity list and the status values — that pinned it down. Why the statuses "aren't understood"You put Workaround now: keep the template Field mapping for your Wallbox
"Cheap" and the tiers you're used toSEM classifies price by percentile of today's prices (cheapest hours), not a fixed cent threshold. Mode "Solar + cheapest hours" gives you: an At least min floor (guaranteed by your target time) + solar surplus above it + a cheapest-hours grid top-up to your target. The one thing it doesn't do is your addon's absolute-price tiering ("charge fully only if prices are really low") — the target is fixed, not raised dynamically when it's ultra-cheap. Say the word if you'd like that noted as an enhancement. Wallbox load-balancing vs SEMSEM controls by setting max charging current + pause/resume. Your Wallbox's Power Boost / |
|
Thanks a lot for the detailed infor. I will try to get ti to work baes on you description. One more question though. In the ENODe connection to my XPENG, I have th eoption of using charge control. |
|
Short answer: no — keep pause/resume on the Wallbox. SEM doesn't charge by switching on and off, it charges by modulating current. Following surplus means walking the setpoint 6 A → 16 A → 9 A as clouds pass, on a 10-second loop, with smoothing and ramp limits so the contactor isn't cycled. A car-side "demanding charge / not demanding charge" toggle can only say on or off, and it says it through XPENG's cloud to a car that is usually asleep — seconds to minutes of lag, on the one path where SEM has no way to confirm what landed. There's also a plain rule underneath: one hand on the contactor. If the car can refuse independently, SEM commands 16 A, sees 0 W, and starts diagnosing a charger that isn't broken. So: Maximum charging current + Pause/resume, both on the Wallbox, both auto-detected. The status sensor — my earlier advice was a workaround, and it's now unnecessaryForget the template binary sensor. That was me routing around a bug in SEM instead of fixing it, and the bug is now fixed. Point Connection straight at The cause was two lists answering one question. SEM has had a single cross-brand status vocabulary since #548 — it always understood your box's full set ( Adding those two strings would have fixed your install and left the drift in place, so the private copy is deleted and both readers now share the one vocabulary. Verified on a live instance against your exact six states:
It's in the next 2.0 beta (#833). One side effect you may benefit from: the charging reader had the same drift, so several brands' charging states — including V2G discharge — were reading as "not charging" and now don't. You shouldn't have to hand-build sensors to describe hardware SEM already supports. Where a custom sensor genuinely fits, SEM takes it — but not as a patch for our own gap. PricesYou don't need to hand-tune thresholds either. Point SEM at whatever price sensor you already have (Nord Pool, Tibber, aWATTar, or your own template sensor — anything that reports a price). SEM then classifies every hour into very cheap / cheap / normal / expensive / very expensive, by default from the shape of the day's actual prices rather than from fixed cutoffs, so it keeps working when the market moves and you don't maintain the numbers. If you prefer hard cutoffs, there's a static mode where you set the cheap and expensive prices directly. With Solar + cheapest hours you get what your old addon gave you: a guaranteed minimum by your target time, solar surplus above that, and a cheapest-hours grid top-up to your target. One thing to checkThree things can now decide when your car charges: SEM, the Wallbox's own The car-side schedule is the nasty one because it fails silently — SEM commands current, the contactor closes, nothing flows, and it looks exactly like a broken charger. Where ENODE still earns its placeState of charge. Your Wallbox exposes |
|
Thanks again for the detailed and good description. I did setup the binary switch you mentioned earlier, but in the opposite way, telling it what is considered as connected instead. I have never gotten the charger to start so far, to see the change in current performed by SEM. I noticed that the following text in the Wallbox integration (Native) I presume this will have not effect on SEM, other than a delay? Regarding my earlier question on the ENODE/Car connection, this was related to if the Car charge demand should/could be used instead of the Pause/Resume of the Wallbox integration. Byt he way, Wallbox does not report SOC as AC chargers normally cannot read the SOC from the Vehicle as SOC is only implemented in the DC charging communication standard. AC is simple and relies on Power, Current, Voltage and energy added. P.S.
|
|
I installed 2.0 Beta 20 this morning and it seems to sort out the issue with the unrecognized status description of the Walllbox Commander 2, thank you |
Uh oh!
There was an error while loading. Please reload this page.
Hi everyone,
maybe som enoe can help me with the following situation:
I have a Wallbox Commander 2 charger and a XPENG EV.
Wallbox is integrated to HA and the EV as well over ENODE.
However, it seems enode only reports the plugged in status during DC charging. FOr the remaining time it states unplugged.
How do I habde this in SEM?
Does SEM work without he plugged in status? Should I just leave it blank i the setup?
Do I have to create a separate plugin signal tht is constantly on?
Any ideas on how to get it to work?
All reactions