V1.3.0-beta3.5

[remmob]

New beta version released with:

🔧 Sensor Improvements

Added optional min/max metadata for sensors, enabling richer UI presentation and better downstream validation.

Introduced runtime sensor filtering, currently validated using the Compressor speed sensor. This allows dynamic inclusion/exclusion without requiring restarts.

🔌 Modbus Stability Enhancements

Communication reliability has been significantly strengthened:

Additional socket‑level error handling ensures cleaner recovery from transient failures.

The integration now forces a reconnect when a Modbus error frame is received.

A 5‑minute inactivity watchdog triggers an automatic reconnect if no successful reads occur within that window.




Aangezien er waarschijnlijk niet veel mensen buiten NL een Amber hebben geïnstalleerd, mogen de discussies in het Nederlands.

[Getiem]

Zojuist geïnstalleerd.

[Florissilfhout]

Is er een kleine typfout ingeslopen? V1.0.3-beta3.5 vs V1.3.0-beta3.5 ;)

[Florissilfhout]

In ieder geval nu ook net deze versie geïnstalleerd, ben benieuwd!

[remmob]

Ik was iets te snel, maar als goed is staat het nu wel goed.

Stond gelukkig wel goed in hwt manifest, dat vergeet ik ook jog wel eens.

[Getiem]

Update systeem begon te piepen dat de reguliere versie nu nieuwer was ;)

[remmob]

Ik hoop de reconnect nu wel goed gaat.
Bij verlies van netwerk verbinding ging het al goed.
Alleen niet bij verlies tussen de module en de amber.

@Getiem ik heb aan de compressor frequentie een bandbreedte voor de sensor gegeven. Spiked hij hoger dan 90 of onder 0, dan blijft de oude waarde staan.
Even aankijken, want dat gebeurt bij mij heel soms.

De waardes die ingesteld kunnen worden daar werkt het ook op.
Je hebt maar beperkt properties die je kunt meegeven.
Dat is dus native_min/max_value geworden.
Die had ik algebruikt om de sliders bandbreedte te geven.

Als je andere sensors hebt die je graag wil, geef maar aan.
Zal kijken of ik dat vanmiddag nog kan verwerken.

[Getiem]

Jouw reconnect was vandaag goed. En sneller dan mijn eigen reconnect automation.

top dat je een min/max hebt staan op compressor. Neem aan dat ie nu op 0-90 staat.

de spikes (up of down) komen al sinds 2 bèta’s terug niet meer voor. Heeft ook met mijn aangepaste Modbus settings te maken volgens mij.

[Getiem]

Reconnect en de simultane poging om toch nog waarden op te halen.

onderste/eerste is een peer connection reset

reconnect lukt uiteindelijk wel.

[Getiem]

Er zijn meerdere waarden die op onbekend zijn gegaan sinds de laatste bèta.

waaronder heatcurve van zone 2,
Restart

[remmob]

Dat is apart, hier niets van terug te vinden, staat er iets in het log?

[remmob]

Gek,
Hier gaat het prima, maar zonder log, kan er niet veel mee.

[Getiem]

Zal even de debug log aanzetten

[Florissilfhout]

Ik ondervind exact hetzelfde als Getiem, dezelfde entiteiten naar 'onbekend', sinds update naar beta3.5.

[Florissilfhout]

Hier is mijn log:
home-assistant_itho_amber_2026-01-26T07-09-25.089Z.log

[Florissilfhout]

Het lijkt erop dat enkele (standaard?) waarden buiten je huidige scope vallen en daardoor genegeerd worden.

[remmob]

Hebben jullie de GND aangesloten van de modbus?
die kan namelijk beter los.

[Florissilfhout]

Niet aangesloten, enkel data - en data +.

[Getiem]

Alleen de twee draden.

[remmob]

Hebben jullie nog steeds onbekende waardes in de instellingen staan, dan ben ik benieuwd of het alleen de instelbare instellingen zijn.
Ik vermoed dat het komt door verminkte/onvolledige data, welke vervolgens buiten de bandbreedte valt. Althans dat zegt jouw log @Florissilfhout

voorbeeld:

• Je ziet herhaaldelijk meldingen als:
  Amber restart dhw vacation mode: Value 20 below minimum 25, ignoring
  Amber Heatcurve-2 setpoint-1: Value 55 above maximum 45, ignoring
  Amber reduced mode delta: Value 30 above maximum 10, ignoring
• Dit betekent dat de integratie waarden uit het apparaat leest die buiten de in Home Assistant ingestelde (of door de integratie verwachte)
  grenzen vallen. Deze waarden worden genegeerd en niet doorgegeven aan Home Assistant.

Uiteindelijk zie je wel:
Finished fetching Amber data in 1.4xx seconds (success: True)

[Getiem]

Ok, ik heb alle waardes (die toch ongebruikt zijn bij mij, anders had ik ze wel anders geconfigureerd), nu binnen de limits gezet die jij in de integratie hebt geprogrammeerd. Ze zijn meteen zichtbaar (zonder herstart). Dus dat was het probleem.
Om de integratie niet de waarde “onbekend” te laten worden voor andere Amber users, zul je mogelijk toch de limits moeten oprekken, gezien de factory defaults die op die entities staan.
voor mij is het nu opgelost. Beta 3.5 werkt voor mij naar behoren.

Ik ben even benieuwd, hoe jij de waardes van die entities anders ingesteld hebt. ter lering voor mij.

en misschien heb ik wel een fout gemaakt, dan pas ik de waardes natuurlijk aan.

Ik ben naar de binnenunit gelopen en heb de waardes gecheckt die ik hierboven in de log terug vond, waarvan jouw code zegt dat ze buiten limits waren.
Stuk voor stuk stonden ze daadwerkelijk op de verkregen waarde. Dus modbus uitlezing was goed.
Via touch screen heb ik de waardes naar een waarde verlaagd die volgens jouw code wel binnen limits is, en dan is uitlezing wederom prima, check limits verloopt dan wel goed en worden ze dus ook prima weergegeven binnen HA.

Ging dus als volgt:
Waarde amber binnenunit (zone 2 heating 55c) —> modbus waveshare —> integratie (value 55c found) —> check limits—> out of range, dus onbekend.

Nu zone 2 heating via touchscreen dus naar 40c gezet, en je check limits functie keurt ze wel goed.

[remmob]

Ohw, nu snap ik het denk ik. deze waardes van zone 2 had jij nooit aangepast.
die stond idd op max 55.
dus dan concludeer ik dat de check functie tussen de waarde controleert, maar de
maximale en minimale niet mee rekent als goed.
55 zal fout geven, maar 54 niet.

Dat ga ik v/d week even testen en dan pas ik de functie aan.

[Getiem]

Ohw, nu snap ik het denk ik. deze waardes van zone 2 had jij nooit aangepast. die stond idd op max 55. dus dan concludeer ik dat de check functie tussen de waarde controleert, maar de maximale en minimale niet mee rekent als goed. 55 zal fout geven, maar 54 niet.

Dat ga ik v/d week even testen en dan pas ik de functie aan.

Nee, zie log: in jouw limit staat deze op max 45. Dan is 55 volgens die check duidelijk out of limit, maar volgens de Itho is het een factory default en zou dus goedgekeurd moeten worden.
#40 (reply in thread)

Evenals dus vacation mode, reduced mode dus een check doen op een waarde, waarbij jij de limit veel strenger hebt dan de default waarde van Itho.

[Getiem]

De default waardes van Itho staan in hoofdstuk 8.1 van de handleiding. Mijn oorspronkelijke waarden waren dus default en dus geldig. Denkbaar je die waarde dus sowieso binnen de default limits van jouw check moet hebben .

[remmob]

Ik had ze gevonden, ga er morgen naar kijken

[bochelork]

Bedankt voor de nieuwe versie. Heb jij het idee dat je met wensen bij itho kan aankomen en dat je deze serieus genomen worden? Het cop verhaal klinkt interessant, maar één parameter zou ik heel graag remote willen wijzigen die nu alleen op de binnenunit staat: de max compressor toerental in het menu van de geluidsreductie.

[remmob]

Ik heb vandaag met een service manager gesproken van Itho op de VSK beurs.
Hij lijkt wel willend, maar dat leek de vorige ook. en we wachten nog steeds op updates.

Ik heb zijn contact gegevens en zal het een en ander nog naar hem mailen.

Begreep dat de pompen die in de Ambers zitten, flow kunnen meten. (volgens de manager ook de unit van de eerste generatie)
Dat zou betekenen, dat een COP sensor alleen maar software is.
en heb het defrost algoritme onder de aandacht gebracht even als het schrijfbaar maken van alle registers.

Wij waren het eens met elkaar dat (modbus) lijst niet openbaar mag worden, omdat er ook registers tussen zitten die het gas type kunnen aanpassen. Deze wijkt maar 1 nummer af van een register dat we nu al uitlezen. dat is dus super link in verkeerde handen.

er is nu ook iemand die met een ESP de LCD overgenomen heeft, maar het LCD doet toch echt wel wat meer dan in eerste instantie gedacht. Ook daar zou ik zeker heel voorzicht mee zijn. voor je het weet is de pomp gebricked.

[bochelork]

Interessant. De esp hack had ik gelezen ja. Dat was ik niet van plan. Misschien als er genoeg zichtbare parameters instelbaar zijn dat mensen minder snel de neiging hebben om de boel te reverse engineeren met alle gevolgen vandien.

[bochelork]

Ter info:
Ik heb deze nog op unknown staan, Amber reduced mode delta (Max ∆T aanvoertemperatuur geluidreductie). Ik zal thuis de waarde even checken...
logs: Amber reduced mode delta: Value 30 above maximum 10, ignoring.
unknown
min: 2
max: 10
step: 1
mode: slider
unit_of_measurement: °C
device_class: temperature
icon: mdi:water-thermometer-outline
friendly_name: Amber reduced mode delta

[remmob]

Ik heb de waardes aangepast, volgens de Itho handleiding.
Althans bijna alle, zo kan de min aanvoer koelen volgens Itho maar tot 16, maar 7 graden werkt ook.
Had wat gerommel met Github, versie is nu 1.3.0-beta3.9, is ook een nieuwe discussion voor.