AXA Remote v2 icm ESP8266 en HomeAssistant

[damien_demon]

met een ESP32-S2 mini (wemos) krijg ik nu alles door (device en firmware) ook de auto calibratie werkt (tijdens worden nu wel aangepast), maar ook veel garbage (ik vermoed dat de esp8266 dit dus inderdaad niet aan kan).
Op ESP32-S2 krijg ik daarnaast ook veel

code:

[E][uart:015]: Reading from UART timed out at byte 0!

Maar wat ik zo online kan vinden zou dit een specifiek probleem kunnen zijn van de ESP32-S2 (ik krijg deze foutmelding ook als de AXA niet aangesloten is).

Ik vermoed (en ik krijg als het goed is morgen de andere MCP's binnen) dat wanneer ik alles opnieuw soldeer met de ESP32 dat alles dan opgelost gaat zijn (op misschien de " timer out at byte 0" melding na). Met andere woorden de manier van aansluiten / voeden van de MCP het probleem is in deze.
Zodra ik meer weet zal ik weer een update doen.

[Stainless Steel]

Als je het raam open/stop/sluit krijg je nu "Command echo received: " meldingen? Of "No command echo received" meldingen?

[Petervano]

Goedemorgen.

Getest, bij mij werkt alles goed, geen uitval van de d1mini.
Wel heel veel 'garbage' meldingen in de log, ongeveer 15 tot 20 per seconde.
en af en toe:

[07:34:00][E][uart:015]: Reading from UART timed out at byte 0!
[07:34:00][E][axaremote.cover:352]: Timeout while waiting for response
[07:34:00][W][component:237]: Component axaremote.cover took a long time for an operation (1063 ms).
[07:34:00][W][component:238]: Components should block for at most 30 ms.

wat voorbeeld regels uit de logging:

[07:47:59][D][cover:186]: Current Operation: CLOSING
[07:47:59][D][cover:170]: 'Raam-02' - Publishing:
[07:47:59][D][cover:173]: Position: 0%
[07:47:59][D][cover:186]: Current Operation: CLOSING
[07:47:59][I][axaremote.cover:129]: Full Close Duration: 43.6s
[07:47:59][D][axaremote.cover:087]: Unlock Duration: 24.0s
[07:47:59][D][axaremote.cover:088]: Open Duration: 30.5s
[07:47:59][D][axaremote.cover:089]: Close Duration: 30.5s
[07:47:59][D][axaremote.cover:090]: Lock Duration: 13.1s
[07:47:59][D][cover:170]: 'Raam-02' - Publishing:
[07:47:59][D][cover:173]: Position: 0%
[07:47:59][D][cover:186]: Current Operation: IDLE

en:

[07:50:08][D][axaremote.cover:144]: Opened with remote?
[07:50:08][D][cover:170]: 'Raam-02' - Publishing:
[07:50:08][D][cover:173]: Position: 0%
[07:50:08][D][cover:186]: Current Operation: OPENING
[07:50:08][D][cover:170]: 'Raam-02' - Publishing:
[07:50:08][D][cover:173]: Position: 0%
[07:50:08][D][cover:186]: Current Operation: OPENING
[07:50:08][D][cover:170]: 'Raam-02' - Publishing:
[07:50:08][D][cover:173]: Position: 0%
[07:50:08][D][cover:186]: Current Operation: OPENING

[ Voor 55% gewijzigd door Petervano op 26-02-2025 08:05 ]

[damien_demon]

Stainless Steel schreef op dinsdag 25 februari 2025 @ 21:54:
Als je het raam open/stop/sluit krijg je nu "Command echo received: " meldingen? Of "No command echo received" meldingen?

code:

[09:43:09][D][cover:076]: 'Zolderraam' - Setting
[09:43:09][D][cover:084]:   Position: 0%
[09:43:09][D][axaremote.cover:308]: Command: CLOSE
[09:43:09][W][axaremote.cover:338]: No command echo received
[09:43:09][D][axaremote.cover:343]: Response: 200 OK
[09:43:09][D][cover:170]: 'Zolderraam' - Publishing:
[09:43:09][D][cover:173]:   Position: 100%
[09:43:09][D][cover:186]:   Current Operation: CLOSING

is wat ik zie (dus "no Command echo received") met de esp8266 (d1 mini)

als ik dan de ESP32 bekijk krijg ik:

code:

[10:02:13][D][cover:076]: 'Zolderraam' - Setting
[10:02:13][D][cover:084]:   Position: 0%
[10:02:13][D][axaremote.cover:308]: Command: CLOSE
[10:02:13][D][axaremote.cover:331]: Command echo received: CLOSE
[10:02:13][D][axaremote.cover:340]: Response: 200 OK
[10:02:13][D][cover:170]: 'Zolderraam' - Publishing:
[10:02:13][D][cover:173]:   Position: 100%

Dus wel een Command echo (maar ook veel [E][uart:015]: Reading from UART timed out at byte 0!)

[ Voor 25% gewijzigd door damien_demon op 26-02-2025 10:06 . Reden: extra informatie ]

[Stainless Steel]

Ik heb een fix toegevoegd voor de "Reading from UART timed out at byte 0!" melding

@Petervano "Timeout while waiting for response" en "Component axaremote.cover took a long time for an operation (1063 ms)." heeft met elkaar te maken, ik gebruikte namelijk een riante timeout van 1 seconden voor als er geen antwoord komt op een commando. Ik heb deze timeout nu teruggebracht en nu zou de melding minder vaak of in ieder geval dichter bij de 30ms moeten zijn als er geen (valide) antwoord op een commando komt.

@damien_demon Gebruik je bij de ESP8266 en ESP32 het zelfde circuit? Krijg je ook een "Full Close Duration: " melding? Dan zou de auto calibrate ook werken.

Werkt het raam op een positie, zeg 30%, zetten voor jullie ook?

[Petervano]

Geen Timeout meldingen meer.

Geen automatisering uitgeprobeerd naar een vaste positie. Met de stop knop kan ik het raam op een tussenliggende positie zetten:

[13:03:32][D][cover:170]: 'Raam-02' - Publishing:
[13:03:32][D][cover:173]: Position: 77%
[13:03:32][D][cover:186]: Current Operation: CLOSING
[13:03:32][W][axaremote.cover:345]: Garbage received: nLocked
[13:03:32][W][axaremote.cover:345]: Garbage received: nLocked
[13:03:32][W][axaremote.cover:345]: Garbage received: nLocked
[13:03:32][W][axaremote.cover:345]: Garbage received: nLocked
[13:03:32][D][cover:076]: 'Raam-02' - Setting
[13:03:32][D][cover:080]: Command: STOP
[13:03:32][D][axaremote.cover:308]: Command: STOP
[13:03:32][W][axaremote.cover:335]: No command echo received
[13:03:32][D][axaremote.cover:340]: Response: 200 OK
[13:03:32][D][cover:170]: 'Raam-02' - Publishing:
[13:03:32][D][cover:173]: Position: 76%
[13:03:32][D][cover:186]: Current Operation: IDLE

Kan de positie goed uitlezen, hiervoor een template sensor gemaakt:

- sensor:
- name: Stand Raam 02
unique_id: stand_raam_02
state: >
{% set x = state_attr('cover.raam_02', 'current_position') | int(0) %}
{{ {0: 'Dicht',
100: 'Open'}.get(x, 'Bezig') }}

[Stainless Steel]

Je kan de positie toch via de UI op een bepaald percentage zetten? Daar heb je geen automatisering voor nodig.

Ik begrijp het doel van je template sensor niet helemaal

[Petervano]

Via de UI werkt het prima om de status in te stellen:


*

Ik vind het makkelijk om in woorden te zien of het raam open is . Voor tussenliggende posities is de toegevoegde waarde nul, maar ik gebruik ook alleen maar open en dicht.

[Stainless Steel]

Met UI bedoelde eigenlijk de schuif die je krijgt als je de entiteit opent


Als ik via de Development Tools > States > Set state de positie instelt overschrijf je alleen de positie in de database, het raam gaat dan niet naar de betreffende positie

[Petervano]

Werkt:

[Petervano]

Is nu zo'n 6 uur operationeel en geen drop-outs. Ook de gekoppelde (op dezelfde d1mini) BME280 Sensor blijft prima functioneren.
@Stainless Steel Dank voor je inspanningen!

[damien_demon]

Stainless Steel schreef op woensdag 26 februari 2025 @ 12:44:
Ik heb een fix toegevoegd voor de "Reading from UART timed out at byte 0!" melding

@Petervano "Timeout while waiting for response" en "Component axaremote.cover took a long time for an operation (1063 ms)." heeft met elkaar te maken, ik gebruikte namelijk een riante timeout van 1 seconden voor als er geen antwoord komt op een commando. Ik heb deze timeout nu teruggebracht en nu zou de melding minder vaak of in ieder geval dichter bij de 30ms moeten zijn als er geen (valide) antwoord op een commando komt.

@damien_demon Gebruik je bij de ESP8266 en ESP32 het zelfde circuit? Krijg je ook een "Full Close Duration: " melding? Dan zou de auto calibrate ook werken.

Werkt het raam op een positie, zeg 30%, zetten voor jullie ook?

Bij de ESP8266 krijg ik de melding niet, bij de ESP32 wel.
Met de nieuwe aanpassing loopt de ESP8266 in ieder geval niet meer vast na een open Command. Ik ga zo de ESP32 proberen.

Ik gebruik overigens hetzelfde circuit voor beide.

[damien_demon]

Stainless Steel schreef op woensdag 26 februari 2025 @ 12:44:
Ik heb een fix toegevoegd voor de "Reading from UART timed out at byte 0!" melding

@Petervano "Timeout while waiting for response" en "Component axaremote.cover took a long time for an operation (1063 ms)." heeft met elkaar te maken, ik gebruikte namelijk een riante timeout van 1 seconden voor als er geen antwoord komt op een commando. Ik heb deze timeout nu teruggebracht en nu zou de melding minder vaak of in ieder geval dichter bij de 30ms moeten zijn als er geen (valide) antwoord op een commando komt.

@damien_demon Gebruik je bij de ESP8266 en ESP32 het zelfde circuit? Krijg je ook een "Full Close Duration: " melding? Dan zou de auto calibrate ook werken.

Werkt het raam op een positie, zeg 30%, zetten voor jullie ook?

Log bestand nog even door laten lopen: op beide krijg ik soms nog de UART timer out melding te zien (alleen veel minder frequent dan eerder)
ESP8266: veel garbage op de lijn (lijkt de werking verder niet te beïnvloeden), ik krijg een aanpassing van de tijd bij auto calibrate, echo is er niet (maar ook dat lijkt de werking niet te beïnvloeden). Tot nu toe geen vastloper na openen (wat eerder wel gebeurde).
ESP32: garbage melding dan direct gevolgd door de 10x UART timer out melding (als het raam beweegt), geen melding van garbage of timer out als er geen beweging is totdat hij closed meld dan stromen de garbage melding weer binnen (met UART timed out).
Gezien dat er duidelijk verschil is in de meldingen wanneer er beweging is; zou de garbage (of uitblijven daarvan) ook kunnen door een voltage drop op het moment dat er beweging is? (de voeding loopt in mijn geval door de ESP heen).

Percentage openen werkt voor beide chipsets perfect! (nogmaals dank voor alle energie die jullie er insteken!)

[Petervano]

Was mij ook al opgevallen dat de garbage regels veel minder waren als er aktie is.

Zou haast denken dat het een initialisatie probleem van de logging is, maar ik heb er verder geen idee van hoe de code in elkaar zit en werkt. Dus misschien maak ik wel een hele domme opmerking.

[Stainless Steel]

@damien_demon zorg er voor dat je ook daadwerkelijk de laatste code van GitHub gebruikt, standaard wordt de code uit de GitHub URL door ESPHome 1x per 24 uur ververst.

Je kan er voor zorgen dat de GitHub code bij elke compilatie opnieuw van GitHub wordt gehaald door een refresh van 0 seconden te configureren:

code:

external_components:
  - source: github://rrooggiieerr/esphome-axaremote
    refresh: 0s

Gezien het verschil in gedrag tussen ESP8266 en ESP32 lijkt het me duidelijk dat een ESP8266 eigenlijk niet echt geschikt is vanwege de softwarematige UART.

[damien_demon]

Stainless Steel schreef op woensdag 26 februari 2025 @ 17:31:
@damien_demon zorg er voor dat je ook daadwerkelijk de laatste code van GitHub gebruikt, standaard wordt de code uit de GitHub URL door ESPHome 1x per 24 uur ververst.

Je kan er voor zorgen dat de GitHub code bij elke compilatie opnieuw van GitHub wordt gehaald door een refresh van 0 seconden te configureren:

code:

external_components:
  - source: github://rrooggiieerr/esphome-axaremote
    refresh: 0s

Gezien het verschil in gedrag tussen ESP8266 en ESP8266 lijkt het me duidelijk dat een ESP8266 eigenlijk niet echt geschikt is vanwege de softwarematige UART.

Ah! dat zorgt voor geen errors meer, alleen de warnings (garbage), dit is op de esp8266 (ik kan nu de esp32 even niet testen)

Ik denk dat de esp8266 inderdaad wat moeite heeft met het UART deel (softserial). Als het goed is krijg ik morgen de MCP’s binnen, dan kan ik die ook testen (of de voeding hier ook een rol in speelt)

[Petervano]

Helaas, gisteravond om half 12 de d1mini uitgevallen.
Vanmorgen alleen kunnen herstarten door de stroom er af te halen.
Ik kijk het nog even verder aan.

[damien_demon]

Petervano schreef op donderdag 27 februari 2025 @ 08:24:
Helaas, gisteravond om half 12 de d1mini uitgevallen.
Vanmorgen alleen kunnen herstarten door de stroom er af te halen.
Ik kijk het nog even verder aan.

Als ik de logbestanden even snel terug kijk is bij mij op de ESP8266 3x weggevallen (maar is wel iedere keer weer zelf terug gekomen). Dat er een reboot is geweest weet ik wel zeker aangezien de tijd van openen weer terug op de basis staat in plaats van de aangepaste "auto calibrate".
Grappige is wel dat na een een "softboot" de AXA wel gesloten blijft aangeven (in plaats van open bij een gesloten raam na een reboot door de stroom er af te halen).

[Petervano]

Inmiddels 2 keer een reboot gehad.
De d1mini houdt het zo'n 11 uur vol en dan volgt een reboot.
De oude versie loopt nu al zo'n 40 dagen zonder reboot. Ik heb 2 identieke installaties, waarvan 1 dus nog niet geupgrade.
Eigenlijk is dit onwerkbaar, te onbetrouwbaar voor mij.

[Petervano]

Ben terug naar de oude configuratie. Heb nu verder geen tijd.
Ik ga de 2 d1mini's op termijn wel een keer ombouwen naar 1 ESP32 om daarmee beide raamopeners aan te sturen.
@damien_demon Ik ben benieuwd of jij nog verder gekomen bent met de ESP32.
@Stainless Steel Helaas kan ik jouw oplossing dus nu helaas niet gebruiken, maar hopelijk komt dit later nog.

[damien_demon]

@Petervano ik heb vanavond de esp32 terug aangesloten en via de usb de voeding laten lopen (zoals de setup van galagaking); ik kreeg geen boot als ik de rx lijn liet voeden door de mcp ( gek maar als ik de voeding over de 5v of de 3.3v van de esp laat lopen wil de boel wel opstarten)
Maar goed ik heb al usb voedingen liggen dus nu eerst zo aangesloten. Ik krijg nu wel verl:

code:

[20:20:58][W][axaremote.cover:349]: Garbage received: STATUS\xe611 Strong Locked
[20:20:58][E][axaremote.cover:357]: Timeout while waiting for response
[20:21:01][W][axaremote.cover:349]: Garbage received: STATUS\xe611 Strong Locked
[20:21:01][E][axaremote.cover:357]: Timeout while waiting for response
[20:21:03][W][axaremote.cover:349]: Garbage received: STATUS\xa3\x93{s;Locked
[20:21:03][E][axaremote.cover:357]: Timeout while waiting for response
[20:21:04][W][axaremote.cover:349]: Garbage received: STATUS\xa3\x93{s;Locked
[20:21:04][E][axaremote.cover:357]: Timeout while waiting for response
[20:21:04][W][axaremote.cover:349]: Garbage received: STATUS\xe611 Strong Locked
[20:21:04][E][axaremote.cover:357]: Timeout while waiting for response

Verder lijkt het stabiel te zijn. Ik laat het jullie weten hoe het komende week gaat.

[damien_demon]

Tot nu toe geen vastlopers of uitvallen gehad op de esp32.

[damien_demon]

De ESP32 is al een hele week stabiel in home assistant aanwezig en alleen komen te vervallen door een update, dus stabiel gebleven (ook stabiel met de garbage meldingen en timeouts, maar dat zorgt verder niet voor instabiliteit of onbereikbaarheid).

[-Tim-]

elleP schreef op donderdag 20 oktober 2022 @ 21:06:
Ik heb toevallig vandaag mijn eerste unit helemaal omgebouwd.

Ik heb als bordje een ESP32-S2 uitgezocht, deze zou iets zuiniger moeten zijn dan een ESP32.
Stom toevallig past het bordje precies in de lege ruimte naast de batterijen in de AXA.

[Afbeelding]	Wemos ESP32-S2 mini met 33Ohm smd weerstand tussen pin17(RX) en pin21(TX) De databus zit met groen aan pin 17 De +3v3 zit met zwart(!) aan de plus van de RJ12 connector De GND zit met rood(!) aan de min van de RJ12
[Afbeelding]	ESP netjes in het hoekje. Datakabel via het daarvoor bestemde gootje netjes weggwerkt Met 2 metalen strips en zelfklevend plastic een aftapunit voor de batterijen gemaakt, bat-plus op vbus van de esp, bat-min op gnd
[Afbeelding]	Alles op zijn plek
[Afbeelding]	Niets van te zien

Over de batterijduur kan ik nog niets zinnigs zeggen, voorlopig draai ik de code van @galagaking met een ander bordje en andere pinnen, maar ik ga kijken of ik met wat strategisch geplaatste 'deep sleep' commandos het voor elkaar kan krijgen om elke x minuten even wakker te worden.

Alle mooie PCB’s daargelaten: deze hardware-aanpak van @elleP is natuurlijk wel erg elegant. Ik heb het topic doorgelezen, maar het is me niet helemaal duidelijk of deze hardware-hack uiteindelijk een doodlopend pad bleek. De oorspronkelijke wens om het geheel op batterijen draaiend te krijgen snap ik heel goed, maar zoals eerder benoemd: dat ding moet continu (al is het op intervals) blijven luisteren. Dus zelfs met een alternatief zoals ZigBee zal het batterijverbruik relatief hoog blijven.

Maar goed, terug naar mijn vraag: een ESP32 in de behuizing plaatsen en dan een stroomkabeltje trekken (naar die RJ11, of via een “USB battery eliminator”) is dat geen werkbare optie?

[elleP]

@-Tim- TNX

Qua hardware werkte het prima, de axa kon zelfs gevoed worden via de 5v usb (hij werkt ook op 4 oplaadbare batterijen, dat is maar 4.8v)

Ik liep uiteindelijk stuk op mechanische problemen.

[tcw82]

elleP schreef op dinsdag 22 april 2025 @ 07:28:
@-Tim- TNX

Qua hardware werkte het prima, de axa kon zelfs gevoed worden via de 5v usb (hij werkt ook op 4 oplaadbare batterijen, dat is maar 4.8v)

Ik liep uiteindelijk stuk op mechanische problemen.

Mag ik vragen wat het mechanisch probleem was?

[elleP]

Jazeker, Ik heb mijn espaxa 2ehands gekocht, dus ik heb geen boormal.

Dat is blijkbaar wel echt nodig, hij werkte wel 1x, maar bij het sluiten wrong hij ergens zo hard dat ik de hele unit uit elkaar moest halen (tot 2x toe).

Toen was ik er wel even klaar mee

[tcw82]

elleP schreef op dinsdag 22 april 2025 @ 15:18:
Jazeker, Ik heb mijn espaxa 2ehands gekocht, dus ik heb geen boormal.

Dat is blijkbaar wel echt nodig, hij werkte wel 1x, maar bij het sluiten wrong hij ergens zo hard dat ik de hele unit uit elkaar moest halen (tot 2x toe).

Toen was ik er wel even klaar mee

Herkenbaar, maar niet onoverkomelijk. Ik heb wel een boormal voor je.
Of is het nu te laat?

[elleP]

@tcw82 het is nog niet te laat, ik heb er nog 4 in een bakje liggen. Zolang ik op mijn kantoor begin en niet op de slaapkamer kom ik er wel mee weg bij mijn vrouw.
Dus als je een boormal voor me hebt, graag!

[tcw82]

elleP schreef op dinsdag 22 april 2025 @ 21:57:
@tcw82 het is nog niet te laat, ik heb er nog 4 in een bakje liggen. Zolang ik op mijn kantoor begin en niet op de slaapkamer kom ik er wel mee weg bij mijn vrouw.
Dus als je een boormal voor me hebt, graag!

Je hebt een prive berichtje, dan kijken we daar even wat handig is.

[timminater]

Iemand die deze boormal kan plaatsen? Als het een beetje meezit hoop ik hem te converteren naar een 3D print zodat ik er meerdere kan printen. Ik heb namelijk nog een stuk of 10 stuks 2e hands units liggen.
Iemand al geprobeerd met een recente ESP32-C6 zodat je in de toekomst over kunt naar zigbee of thread? Of de ESP32-C3 met bijvoorbeeld sleep van 30 sec en mqtt retain? Een vertraging van 30 sec op mijn raam vind ik nog niet zo interessant namelijk, batterij voeding is voor mij wel een nood.

[-Tim-]

timminater schreef op woensdag 23 april 2025 @ 18:45:
Iemand die deze boormal kan plaatsen? Als het een beetje meezit hoop ik hem te converteren naar een 3D print zodat ik er meerdere kan printen. Ik heb namelijk nog een stuk of 10 stuks 2e hands units liggen.
Iemand al geprobeerd met een recente ESP32-C6 zodat je in de toekomst over kunt naar zigbee of thread? Of de ESP32-C3 met bijvoorbeeld sleep van 30 sec en mqtt retain? Een vertraging van 30 sec op mijn raam vind ik nog niet zo interessant namelijk, batterij voeding is voor mij wel een nood.

Ik krijg morgen mijn eerste Axa Remote binnen, zal ook eens kijken of ik hem naar een 3D model kan omzetten. Misschien is het zelfs wel met een A4 printje op schaal te doen? Ik heb (nog) geen idee hoe zo'n ding er uit ziet

---

Die ESP32-C6 heb ik ook naar gekeken, en ik zat ook al te dromen over Zigbee support er mee. Vooral de Xiao ESP32 schijnt veel documentatie en examples te hebben, dus ik zag wel mogelijkheden. Echter, en ik kan het mis hebben, zijn al die esp32 implemntaties meer bedoelt voor end-devices, die zelf alleen uitzenden. Zoals een PIR of temperatuur sensor. Ons apparaat zal echter om de zoveel tijd wakker moeten worden (of op een externe interrupt).

Maar max. 30 seconde delay lijkt mij ook prima. 's Nachts zou dat zelfs naar 30 minuten opgeschroefd kunnen worden voor verdere besparing. Ik kwam onlangs deze post nog tegen op Reddit, van iemand die geloof ik tot 8 jaar claimt op 3x L91 AA batterijen. Wel met een wake-up interval van een uur.
Misschien valt uit zijn esphome configs nog wat te leren.

Ik ga er graag binnenkort mee bezig, vandaar dat ik ook even vroeg of er inherent iets verkeerd was aan @elleP s aanpak met gewoon direct de ESP32 er op/in. Want dan wordt het dus meer een software kwestie.

En anders ga ik een extern zonnepaneeltje overwegen

[tcw82]

Het ziet er zo uit.
Ik denk dat ik morgenmiddag ook wel een stl kan maken.
(Inscannen van de twee zijde mee een mm schaalverdeling erbij).

[JBS]

Ik heb ook nog zo'n boormal, omgeving Eindhoven.

[-Tim-]

Mijn eerste Axa Remote is nog onderweg, maar ik ben al wat verder in de gedachte om een batterijgevoede ESP32 toe te voegen (wederom, naar @ellePs voorbeeld)

Mijn aanname is dat het gebruik van een ESP32-devboardje, hoe klein ook, altijd extra quiescent current introduceert (LEDs, USB-serial converter, enzovoort).

Daarom heb ik gekozen voor een barebones castellated-edge module, zodat het toch nog enigszins soldeerbaar blijft. Samen met een LDO-regelaar die geschikt is voor 4×AA-batterijen en een quiescent current van ongeveer 8 µA, zou het geheel in slaapstand een zeer laag verbruik moeten hebben.

Vervolgens heb ik via ChatGPT de YAML-configs van een ander AA-gevoed ESPHome-project laten analyseren (ik heb het zelf nog niet gecheckt). Blijkbaar heeft die persoon de slaaptijd variabel instelbaar aan de Home Assistant kant gemaakt, wat mogelijkheden biedt om slimme slaapintervallen te gebruiken: bijvoorbeeld ’s nachts elk uur wakker worden, en op tijden dat er mensen thuis zijn elke minuut.

Benieuwd wat jullie van m'n, vooralsnog theoretische, aanpak vinden!

[tcw82]

Ik denk dat ik hem heb. Een stl. Ik ben hem nu aan het printen en dan zal ik hem vergelijken met bestaande. Ik heb ook enkele scans met een mm verdeling erbij. Die zal ik straks met een linkje naar de stl hier delen.

[tcw82]

Net met mach Jezus dit printje gemaakt. Straks even de uitlijning testen met een paar plankjes.

[tcw82]

Zojuist de STL op thingiverse gezet:
https://www.thingiverse.com/thing:7019424

Ik heb hem getest, de gaten lijnen uit.

[tcw82]

Ik denk dat ik hem heb. Een stl. Ik ben hem nu aan het printen en dan zal ik hem vergelijken met bestaande. Ik heb ook enkele scans met een mm verdeling erbij. Die zal ik straks met een linkje naar de stl hier delen.
@timminater @elleP @-Tim- .

Als er interesse is, heb ik ook de scan met lineaal plaatjes.

[joneboon]

Hoi allemaal,

ik heb een probleem met de AXA die ik eigenlijk nog niet voorbij heb zien komen.

Ik kan de raamopener prima besturen met een esp, maar ik loop tegen een probleem aan dat als het raam in zijn verste positie staat het systeem over zijn nek gaat. Dan reset de raamopener intern en is de positie weer LOCKED. Druk ik dan weer op openen, dan gaat ie weer over zijn nek.

Ik heb dit probleem alleen maar als ik hem via de RJ12 plug bedien, met de batterijen gaat het prima. Mijn vermoeden: het laatste stukje openen gebruikt te veel vermogen waardoor de voltage dropt en de raamopener opnieuw opstart. Heeft iemand hier ook last van gehad? Ik gebruik een RPi3 voeding voor mn bordje, daar zit een buck converter op naar 8V om de AXA te voeden.

[damien_demon]

joneboon schreef op zondag 8 juni 2025 @ 16:34:
Hoi allemaal,

ik heb een probleem met de AXA die ik eigenlijk nog niet voorbij heb zien komen.

Ik kan de raamopener prima besturen met een esp, maar ik loop tegen een probleem aan dat als het raam in zijn verste positie staat het systeem over zijn nek gaat. Dan reset de raamopener intern en is de positie weer LOCKED. Druk ik dan weer op openen, dan gaat ie weer over zijn nek.

Ik heb dit probleem alleen maar als ik hem via de RJ12 plug bedien, met de batterijen gaat het prima. Mijn vermoeden: het laatste stukje openen gebruikt te veel vermogen waardoor de voltage dropt en de raamopener opnieuw opstart. Heeft iemand hier ook last van gehad? Ik gebruik een RPi3 voeding voor mn bordje, daar zit een buck converter op naar 8V om de AXA te voeden.

En wat gebeurd er als je het raam met de afstandsbediening aanstuurt? Dus niet met de ESP? Gaat het systeem dan ook “over zijn nek”?

[joneboon]

damien_demon schreef op zondag 8 juni 2025 @ 16:43:
[...]


En wat gebeurd er als je het raam met de afstandsbediening aanstuurt? Dus niet met de ESP? Gaat het systeem dan ook “over zijn nek”?

gaat ook fout met de afstandbediening.

Ik heb in de tussentijd nog iets meer getest. Als het raam open is en er dan de stroom er van af gaat, dan komt ie in deze staat. Ik kan het raam prima besturen met de ESP, helemaal open en dicht (dacht eerst dat ie altijd in het uiteinde over zijn nek ging maar dat is toch niet het geval).

Om hem uit de hardware-reset-loop te halen moet ik de batterijen er in doen, raam weer dicht laten gaan en dan kan de RJ12 connector er weer in.

Zou fijn zijn als de AXA niet LOCKED zou zijn als er een power outage is geweest, lijkt me ook een veiligheid dingetje eerlijk gezegd.

[Stainless Steel]

Het klopt inderdaad dat de AXA in Locked state is na een power reset, onafhankelijk van de echte status van het raam. Heel vervelend want daardoor kan de code eigenlijk niet vertrouwen op de status die de AXA terug geeft

[tcw82]

@joneboon Is het mogelijk om een timertje te gebruiken die het raam tot t-x laat open sturen. Dan kun je het raam laten openen tot net niet die max stand?
Of een max open is 95%?

[ Voor 11% gewijzigd door tcw82 op 08-06-2025 17:23 ]

[joneboon]

tcw82 schreef op zondag 8 juni 2025 @ 17:22:
@joneboon Is het mogelijk om een timertje te gebruiken die het raam tot t-x laat open sturen. Dan kun je het raam laten openen tot net niet die max stand?
Of een max open is 95%?

ik had hem net ook even met de batterijen iets terug laten lopen, dus naar 95% ofzo. Daarna batterijen er weer uit en RJ12 connector er weer in, dan kom ik in dezelfde situatie terecht helaas.

wat ik wel interessant vind is dat met 4x AA batterijen het helemaal ok gaat, zit er misschien een extra capacitor op de interne PCB bij de batterijen kant? en niet aan de RJ connector kant? Zijn er plaatjes van de interne PCB toevallig?

[tcw82]

Ik zie dat je 8volt naar via de Converter naar de Axa unit stuurt, 4*1.5 is 6 volt voor de batterijen. Het zou toch niet een over voltage zijn?

[Stainless Steel]

De officiële AXA voeding geeft 7.5 Volt, ik voed mijn AXAs met 9 Volt, maar 12 Volt werkt ook nog. Bij een hoger Voltage gaan ze sneller open/dicht, maar maken ze ook meer geluid.

Ik denk dat in dit geval de voeding, of buck converter niet genoeg vermogen kan leveren waardoor het Voltage dropt

[tcw82]

Stainless Steel schreef op maandag 9 juni 2025 @ 09:05:
De officiële AXA voeding geeft 7.5 Volt, ik voed mijn AXAs met 9 Volt, maar 12 Volt werkt ook nog. Bij een hoger Voltage gaan ze sneller open/dicht, maar maken ze ook meer geluid.

Ik denk dat in dit geval de voeding, of buck converter niet genoeg vermogen kan leveren waardoor het Voltage dropt

Ik weet niet genoeg van de precieze werking van de Axa en of de converters.

Is twee (converters) parallel zetten voor meer vermogen een idee. Ze zijn niet zo duur (ik gebruik ze voor de printers). Of een (dikke) condensator er tussen die de pieken kan opvangen. Je schakelt niet elke 2 seconden met zo een raam is mijn ervaring. Dan heeft een (dikke) condensator de tijd om op te laden voor het volgende kunstje.

[joneboon]

ik heb de raamopener even los liggen hier, kan het resetten goed reproduceren ook zonder een raam gekoppeld te hebben.

Als ik de vergrendel motor los koppel van de interne PCB dan lijkt alles prima te werken als ik hem voed via de RJ12 poort. Waarom dat is weet ik nog niet, deze motor wordt wel ook gelijk aangestuurd bij openen na een power reset (omdat de status LOCKED is).

[Stainless Steel]

tcw82 schreef op maandag 9 juni 2025 @ 09:43:
[...]
Is twee (converters) parallel zetten voor meer vermogen een idee.

Ik zou de AXA gewoon direct met 9 Volt voeden en dan met een step down converter van 9 Volt naar 3.3 Volt gaan om de ESP te voeden. Zo doe ik dat althans zelf op mijn PCB.

De ESP heeft niet zoveel vermogen nodig, de motor van de AXA wel

[joneboon]

Opgelost! Een paar problemen:
Het vergrendel principe is niet super robuust, het wormwiel-asje kon makkelijk vast lopen. Ik heb die een beetje bijgewerkt en nu loopt het soepeler.
Het over zijn nek gaan bij het aansturen van de vergrendel motor heb ik opgelost door een condensator over de batterij polen te zetten. Nu werkt het perfect!