Make the remedy work, and stop blocking weekly schedules - #278
Draft
Poshy163 wants to merge 2 commits into
Draft
Conversation
Three blockers from a b4 diagnostics download on CharlesGillanders#267, all of which the new schedule section made visible at once: enable_intent null, a switch staged, no write ever attempted, and a weekly schedule underneath. The remedy could not be carried out. Every refused write said to set the two switches, but moving a switch only staged it, and the record the write consults was written on a successful write - which could not happen. Worse, the staged flag made the mode indicator read active, so the switch took the staging path rather than the immediate one, and the loop closed. Staging a flag now records it: it is the user's answer either way, and it is a local record rather than a call. Discard puts the previous answer back, so it is still an edit like any other. Adding a period to a weekly schedule was refused outright on the grounds that the two-slot entities cannot choose weekdays. The newer app writes "every day" as a weekly schedule covering all seven, so that refusal blocks most systems on the new backend. A new period now runs on the same days as the period it is added alongside, which is visible in the app and changeable there; with no sibling to copy, it is still refused. The power boxes had a minimum of 1 and a step of 100, so they only accepted 1, 101, 201 and so on - which is why a user asking for 14000 W sent 14001. The step is now 1. The minimum stays 1: a 1 W period is a documented way to force grid-charge mode.
AlphaESS has started answering moneyType with the symbol rather than an ISO code - "€" where it used to send "EUR". Home Assistant's monetary device class only accepts a code, so the symbol had to be resolved before it reached a unit. The mapping already existed in the sensor platform, so the monetary units were never wrong, but two things around it were. The Currency Code sensor reports whatever the API sent, so it now reads "€" - a symbol, from a sensor named for a code, and the same value goes into the diagnostics download. The parser now resolves it once, so both report a code. The other is a symbol that names more than one currency. "$" resolved to USD whatever the owner's currency, which is wrong for every AUD, NZD and CAD system - a good share of them - and "¥" resolved to JPY for a Chinese one. An ambiguous symbol now resolves to the currency Home Assistant is configured for when that is one of the candidates, and to the most common otherwise. An unrecognised value still falls back rather than being guessed at. The mapping moves to its own module so the parser and the sensor platform share one answer, and it gains 元 and Kč on the way through.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Three blockers from b4 diagnostics on #267. The new
schedulesection made all three visible in one download, which is what it was added for.His state:
enable_intent: null, a switch staged in the draft,enable_last_sent: nulland both write cooldownsnull— no write had ever been attempted. That is why the webapp showed no change. Underneath, a weekly schedule and power values of14001/15001.1. The remedy could not be carried out
Every refused write said to set the two switches. But moving a switch only staged it, and the record a write consults was written on a successful write — which could not happen, because the record was empty. Worse, the staged flag made the mode indicator read active, so
can_unlock_time_controls()was false and the switch took the staging path rather than the immediate-write one. The loop closed on itself.Staging a flag now records it. It is the user's answer either way, and it is a local record rather than a call, so there is nothing to fail. Discard puts the previous answer back, so a staged switch is still an edit like any other — the existing discard test caught that immediately.
2. Weekly schedules could not gain a period
Adding a period to a weekly schedule was refused outright, on the grounds that the two-slot entities cannot choose weekdays. But the newer AlphaESS app writes "every day" as a weekly schedule covering all seven days, so that refusal blocks most systems on the new backend — his charge side had one period, all seven days, and his draft was trying to add a second.
A new period now runs on the same days as the period it is added alongside: visible in the app, changeable there, and not a guess. With no sibling to copy from, it is still refused.
3. The power boxes could not accept a round number
native_min_value=1withnative_step=100only accepts 1, 101, 201 … which is exactly why a user asking for 14000 W ended up sending 14001. The step is now 1. The minimum stays 1, because a 1 W period is a documented way to force grid-charge mode — that is what the original report on #267 used.