Bjørn Mork

sannelig. Prøvde nå med v23.05.3 på ex5700 og ser det samme. Kræsjer med (her med funsjonsnavn i stack trace - gjør det litt enklere å grave rundt i mt76): root@OpenWrt:/# [ 203.065843] Unable to handle kernel read from unreadable memory at virtual address 0000000000000024 [ 203.074880] Mem abort info: [ 203.077667] ESR = 0x0000000096000005 [ 203.081399] EC = 0x25: DABT (current EL), IL = 32 bits [ 203.086696] SET = 0, FnV = 0 [ 203.089734] EA = 0, S1PTW = 0 [ 203.092858] FSC = 0x05: level 1 translation fault [ 203.097721] Data abort info: [ 203.100585] ISV = 0, ISS = 0x00000005 [ 203.104402] CM = 0, WnR = 0 [ 203.107358] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000 [ 203.113777] [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000 [ 203.122459] Internal error: Oops: 0000000096000005 [#1] SMP [ 203.128011] Modules linked in: pppoe ppp_async nft_fib_inet nf_flow_table_ipv6 nf_flow_table_ipv4 nf_flow_table_inet pppox ppp_generic nft_reject_ipv6 nft_reject_ipv4 nft_reject_inet nft_reject nft_redir nft_quota nft_objref nft_numgen nft_nat nft_masq nft_log nft_limit nft_hash nft_flow_offload nft_fib_ipv6 nft_fib_ipv4 nft_fib nft_ct nft_counter nft_chain_nat nf_tables nf_nat nf_flow_table nf_conntrack mt7915e mt76_connac_lib mt76 mac80211 cfg80211 slhc nfnetlink nf_reject_ipv6 nf_reject_ipv4 nf_log_syslog nf_defrag_ipv6 nf_defrag_ipv4 mdio_netlink libcrc32c compat crypto_safexcel sha1_generic seqiv md5 des_generic libdes authencesn authenc leds_gpio xhci_plat_hcd xhci_pci xhci_mtk_hcd xhci_hcd gpio_button_hotplug usbcore usb_common aquantia crc_ccitt [ 203.194677] CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0 [ 203.200838] Hardware name: ZyXEL EX5700 (Telenor) (DT) [ 203.205956] pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 203.212897] pc : mt76_wcid_cleanup+0x84/0x22c [mt76] [ 203.217856] lr : mt76_wcid_cleanup+0x64/0x22c [mt76] [ 203.222806] sp : ffffffc00a803700 [ 203.226104] x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00 [ 203.233220] x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001 [ 203.240335] x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8 [ 203.247450] x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000 [ 203.254565] x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0 [ 203.261679] x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000 [ 203.268794] x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28 [ 203.275909] x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000 [ 203.283025] x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001 [ 203.290140] x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024 [ 203.297255] Call trace: [ 203.299686] mt76_wcid_cleanup+0x84/0x22c [mt76] [ 203.304290] __mt76_sta_remove+0x70/0xbc [mt76] [ 203.308806] mt76_sta_state+0x8c/0x1a4 [mt76] [ 203.313148] mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e] [ 203.319313] drv_sta_state+0x144/0x274 [mac80211] [ 203.324028] sta_info_move_state+0x1cc/0x2a4 [mac80211] [ 203.329249] sta_set_sinfo+0xaf8/0xc24 [mac80211] [ 203.333952] sta_info_destroy_addr_bss+0x4c/0x6c [mac80211] [ 203.339520] ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211] [ 203.345782] cfg80211_check_station_change+0x1360/0x4710 [cfg80211] [ 203.352042] genl_family_rcv_msg_doit+0xb4/0x110 [ 203.356647] genl_rcv_msg+0xd0/0x1bc [ 203.360208] netlink_rcv_skb+0x58/0x120 [ 203.364027] genl_rcv+0x34/0x50 [ 203.367154] netlink_unicast+0x1f0/0x2ec [ 203.371061] netlink_sendmsg+0x198/0x3d0 [ 203.374967] ____sys_sendmsg+0x1b0/0x210 [ 203.378876] ___sys_sendmsg+0x80/0xf0 [ 203.382522] __sys_sendmsg+0x44/0xa0 [ 203.386081] __arm64_sys_sendmsg+0x20/0x30 [ 203.390161] invoke_syscall.constprop.0+0x4c/0xe0 [ 203.394849] do_el0_svc+0x40/0xd0 [ 203.398149] el0_svc+0x14/0x4c [ 203.401189] el0t_64_sync_handler+0x100/0x110 [ 203.405529] el0t_64_sync+0x15c/0x160 [ 203.409179] Code: d2800002 910092c0 52800023 f9800011 (885f7c01) [ 203.415252] ---[ end trace 7e42dd9a39ed2281 ]--- [ 203.426754] Kernel panic - not syncing: Oops: Fatal exception in interrupt [ 203.433610] SMP: stopping secondary CPUs [ 203.437517] Kernel Offset: disabled [ 203.440988] CPU features: 0x0,00000000,20000802 [ 203.445501] Memory Limit: none [ 203.455362] Rebooting in 3 seconds.. Må da være mulig å finne ut hvorfor dette skjer. I første omgang får jeg se om problemet er der i master branchen også.

Kanskje det funker med en ikea smartlås for skap/skuff og et rfidkort tapet på fronten av roboten? Og ikke tape kort på hunden https://www.ikea.com/no/no/p/rothult-smartlas-hvit-00359739/ Edit: hmm, nei. Innså at det var en dårlig ide. De låsene smekker vel ikke? Da funker det dårlig. Lage noe tilsvarende med smekk selv, da

interessant! Har en Conbee II liggende uten noe mål og mening fordi, som det står, " there are far better and more capable alternatives out there". Her var jo en mulighet til å gi den litt mening igjen.

Samtidig er det kanskje mulig med tilsvarende ordninger som man har hatt for USB-duppeditter? Der har det i mange tilfeller vært mulig å få sin egen product ID fra produsenten av hardwaren du bruker, med deres vendor ID og tilhørende medlemsskap i USB-IF. Gjerne kostnadsfritt. Jeg fikk f.eks en ID fra Microchip i sin tid basert på en håndfull PIC18LF2550 som jeg labbet litt med. Det gikk jo selvsagt ingen steder. Prosjektet ble til slutt stjålet. Men det var nok mest pga motorsykkelen det satt i.

Hm. Er det noe jeg ikke har fått meg meg her? På https://www.home-assistant.io/docs/authentication/ står det Det kan se ut som de skiller mellom forskjellige grupper som "Owner, Administrator, Read-Only User" under /config/users men i Add User dialogen er det bare mulig å velge Administrator on/off, med kommentaren Dette dekker ikke noen som helst praktisk use case som jeg kan se. Noen eksempler: slomsete samboer som helst ikke skal ha tilgang til å trykke på for mange knapper barn skal kunne styre lys her og der, men får kanskje ikke leke med garasjeporten eller vannkokeren leieboer skal ha full tilgang til alt som dekker hybelen, inkludert lys i fellesområder som gang den som låner hytta skal få midlertidig tilgang til all automagi der, selv om HA-instansen dekker både hus og hytte

Jatakk! Litt usikker på hva jeg synes om at den er satt opp som en "Later priority". Jeg fatter egentlig ikke hva de tenkte på når de designet systemet uteni første omgang.

@Fermate har kommet med løsningen for lenge siden. Du kan jo bare droppe PC-vifta:

Vet at mange har vært entusiastiske lenge når det gjelder esphome. Jeg må innrømme at jeg ikke helt har sett poenget. Men nylig testet jeg ut Blåtann (egentlig BLE) proxy-funksjonen, og den er jo konge! Kjører greit på knøttsmå og billige ESP32C3 moduler. Delt Wifi og Blåtann skal riktignok ikke være så lurt. Har ikke hatt kjempeproblemer utover at det var greit å vente med BLE scanning til nettet var ferdig konfigurert. Men jeg liker kablet nett og jeg liker PoE. Spesielt hvis vi ser for oss en BLE proxy plassert på steder der det ikke er strøm fra før. En slik virket perfekt (men pass på å velge "Color: ETH01-EVO with POE"): https://www.aliexpress.com/item/1005006528549724.html ...bortsett fra at ethernet-modulen ikke var støttet i esphome, da. Optimist som jeg er så bestilte jeg likevel. Det ligger en driver i esp32-idf, som er mer eller mindre obligatorisk uansett med ESP32C3 om jeg har forstått det riktig. Så hvor vanskelig kan det være å legg til i esphome? Ikke vanskelig i det hele tatt, viste det seg. Det var dagens prosjekt: https://github.com/esphome/esphome/pull/6861 Så da gjelder det bare å finne et sted den kan gjøre nytte for seg.

Et par nyttige linker... Zigbee dokumentasjon (ser ikke ut til å være helt stabilisert ennå, så det kan vel være greit å følge med på om det kommer nye versjoner av dette dokumentet). Linken er bla fra https://help.aminacharging.com/en/faq: https://doc.clickup.com/9004130215/p/h/8cb07x7-18308/c750786359b035a Firmware versjon 1.5.3 og oppgraderingsinstruksjoner, fra https://github.com/somlioy/amina_s/issues/7#issuecomment-2142017779 https://doc.clickup.com/9004130215/p/h/8cb07x7-30795/12688a97b1dfa55 Min lader kom med versjon 1.4.10, og der manglet en del av de dokumenterte Zigbee attributtene. Oppgradering over BLE vha Android-appen det refereres i dokumentasjonen til virket fint. Men jeg håper jo virkelig de har tenkt å støtte Zigbee OTA etter hvert.

Spennende! Takk for veldig nyttig info. Mulig jeg tar for lett på dette, men det ser da ut som om det er noe som burde la seg implementere i z2m. Jeg kikket på source for firmwaren du viser til, her: https://github.com/jlama/powertagd/blob/master/firmware/src.zip Der ser jeg // Special ACK frame for Schneider PowerTag GP devices. #define SCHNEIDER_POWERTAG_ACK_CMD 0xFE // with 1 byte (0x00) payload .. uint8_t cmd_id = pop_gp_tx_queue(&gpdAddr, payload, sizeof(payload)); if (cmd_id == 0) { // No entry in TX queue, use default ACK reply cmd_id = SCHNEIDER_POWERTAG_ACK_CMD; payload[0] = 1; // Size of payload payload[1] = 0; // Actual payload } som matcher omtrentlig det vi ser i "PowerTag Commissioning.pcapng" som er linket fra https://github.com/Koenkk/zigbee2mqtt/issues/7975 Der er det noen slike pakker etter diverse rapporter fra tagene: ZGP stub NWK header Data, GPD Src ID: 0xe20765e6 Frame Control Field: 0x8c, Frame Type: Data, NWK Frame Extension Data .... ..00 = Frame Type: Data (0x0) ..00 11.. = Protocol Version: 3 .0.. .... = Auto Commissioning: False 1... .... = NWK Frame Extension: True Extended NWK Frame Control Field: 0x98, Application ID: Unknown, Security Level: Encryption with full frame counter and full MIC, Direction: From ZGPP .... .000 = Application ID: Unknown (0x0) ...1 1... = Security Level: Encryption with full frame counter and full MIC (0x3) ..0. .... = Security Key: False .0.. .... = Rx After Tx: False 1... .... = Direction: From ZGPP (0x1) Src ID: Unknown (0xe20765e6) Security Frame Counter: 2337 Security MIC: 0x794680c5 Command Frame: Unknown Command Frame ZGPD Command ID: Unknown (0xfe) Data (1 byte) 0000 00 . Data: 00 [Length: 1] det burde vel være mulig å få til noe likt i zigbee-herdsman:dist/controller/greenPower.js tror jeg. Men det er rart om ingen har prøvd. Så det er kanskje vanskeligere enn jeg innbiller meg

Kjøpte akkurat et lite utvalg moduler fra https://www.fibel.no/ Kan anbefales om du ønsker å støtte mer lokale forhandlere. Er i postkassen din i løpet av dager, selv om det ikke blir helt det samme som å stikke innom Kjell

Da gjetter på at det er en slik pakke han har: https://www.elko.no/produkter/utgatte-produkter/45-styresystemer/elko-wireless-quick-dim

Noe slikt kanskje? https://www.elektroimportoren.no/frient-smart-io-module/94438/Product.html

Tips i tilfelle noen fremdeles venter: Elektroimporteren har tilbud på Amina S denne uken. Jeg aner ikke hvor bra tilbudet er siden prisjakt ikke gir historikk for dette produktet av en eller annen grunn. Men 4490 for 20A eller 4990 for 32A er uansett såpass grei pris at jeg endte med å kjøpe en til hytta. Fremdeles uten å ha noe el-kjøretøy, men det kommer vel en gang...

Skaff et multimeter og mål pinnene. Ikke prøv blindt! Tror ikke jeg har noe bilde fra ex5700, men jeg er rimelig sikker på at pinout er den samme som feks nr7101. Se https://openwrt.org/toh/zyxel/nr7101#serial Vil tro du har forklaringen på alle problemene der EDIT: når jeg tenkte litt etter så husket jeg at jeg også dokumenterte pinout i commit loggen. Se "UART" linjen: https://github.com/openwrt/openwrt/commit/6cc14bf66aa924962b926ea9702b6153ae418a7d

Nytt for meg, men det er jo selvsagt mulig at det er endret i en nyere batch. Jeg ser at du har en litt nyere U-Boot build enn meg. Nyere Telenor-firmware disabler konsollet fullstendig, så det er normalt at du ikke ser noe mer etter at Linux begynner å boote. Men det påvirker selvsagt ikke bootloaderen Og uansett hvor stengt ned bootloaderen er, så vil https://github.com/981213/mtk_uartboot kunne funke. Ihvertfall så lenge de ikke tar i bruk secure boot. Dette høres mer ut som at det er noe galt med terminalen din. Hva skjer hvis du taster en komplett kommando? F.eks. "help" eller "?"

Sant nok. Er vel kanskje bare styrken på magnetfeltet som betyr noe uanskvett? Men over til neste problem, som heller ikke burde vært noen overraskelse: Det viser seg at løsningen påvirker rekkevidden for de ordinære 433 MHz fjernkontrollene merkbart. Det gir veldig dårlig waf når vi er vant med å åpne porten fra gata nedenfor og bare suse rett inn i åpen garasje. Eneste fornuftige teori er rett og slett interferens. Burde nok ikke plassert en radio så nær fjernkontroll-antenne og styring. Dumt. Så mye for den "elegante" løsningen med ADSL-dongle. Blir nok pent nødt til å bruke litt lenger kabel her. Det er jo en smal sak å fikse Hjelper nada at porten kan styres fra mobifonen eller fullautomatiseres hvis den ikke "virker som før". Regner med dere vet hvordan det er 😉

Lærer stadig ting jeg burde ha visst fra før. Kan det være alderen? Monterte en (hadde ikke flere) av magnetbryterne i dag. Trodde jeg hadde vært på den sikre siden mht påkrevd avstand. Men tenkte ikke på effekten av stålskinner. Rekkevidden ble drastisk lavere når jeg plasserte bryteren der jeg hadde tenkt. Ser ikke noen gode alternativer heller. Ønsker ikke å lage noen voldsomme braketter. Heldigvis ser det ut til at det akkurat gikk med denne plasseringen. Avstand mellom magnet og bryter er vel 1 - 1,5 cm. De funker med mer enn det doble i fritt rom. Men altså ikke når bryteren er limt til en stålskinne Hvordan monterer egentlig folk flest disse tingene? Ser med gru på hvordan dette skulle fungert med et stakkarslig batteridrevet zigbee-sensor f.eks.

Da endte jeg også med en Shelly Plus Uni, selv om planen egentlig var å få brukt opp en Shelly Uni. Ref Dermed er garasjeporten (nesten) automatisert. Neida, ikke så spennende. Eier ikke fantasi. Må bare få montert et par magnetbrytere. Det er hensikten med den ledige RJ45-porten. Der har jeg to ganger jord + inputene til Plus Uni plassert på pinne 1,2 og 7,8. Tok litt tid før jeg skjønte at Plus skal ha inngangene ned i stedet for opp. Lese dokumentasjon? Det er for pingler. Trodde jeg bare kunne bytte ut Unien uten å koble om på innsiden av RJ45-skjøten. Men det gikk jo ikke. Jaja, er vel lurere slik antar jeg. Mindre sjanse for at en fiklepetter som meg dreper en inngang med feil spenning. Den hvite RJ45-kontakten er bare en gjennomkobling av kabelen til motorstyringen. Hadde en kablet bryter i inngang 1 og vil beholde den. Koblingen til motorstyringen er en nedfilt telefonplugg. Dette er en slik dongle med 6P4C plugg og 8P4C kontakt som pleide å følge med ADSL-rutere. Burde selvsagt hatt en ekte 4P4C plugg, men fant ingen. Og hadde jo egentlig tenkt å klare meg uten å kjøpe noe til dette prosjektet. For de som lurer: Port 2 på motorstyringen fungerer bare som stopp og lukk. Port 1 fungerer som åpne, stopp og lukk. Kunne selvsagt koblet det andre releet til port 2. Men så ikke helt hensikten (forutsatt at jeg får på plass sensorene som forteller meg om porten er lukket). Og for de som lurer på pinouten på disse Crawford/Normstahl motorene (det gjorde ihvertfall jeg) så er den jord impulsbryter impulsbryter +35V Jeg fant et dokument som påstod at bryteren skulle koble pinne 3 til jord, men det funket ikke. Det er pinne 2 og 3 som kortsluttes for å trigge start/stopp. Dette gjelder begge impuls-inngangene. Jeg gjetter på at det er nokså likt på de to andre inngangene også, med tilpasninger som at pinne 2 og 3 er RX og TX (eller motsatt?) for fotocellene på inngang 3. Var litt overrasket over at spenningen var såpass høy. Dokumentasjon jeg har funnet sa 24V. Men tar nå uansett sjansen på at Plus Unien også takler det, selv om det er slightly utenfor spec. Ikke all verdens mest avanserte case design, men er fornøyd med hullet jeg borret ved dioden. Etter å ha drept Unien fant jeg det praktisk med et visuelt livstegn 🙂

Så var det på tide med noen tabber igjen. Har hatt en Shelly Uni liggende i en evighet etter et impulskjøp uten mål og mening. Men endelig tok jeg mot til meg og prøvde å bygge den inn i noe nyttig. Var passelig ferdig og skulle bare "teste" litt. Kanskje litt vel slumsete. Mistenker at jeg sendte 9V (som var strømforsyningen jeg testet med) inn på sensor-input. Den falt ihvertfall brått av nett og kom aldri tilbake igjen. Og LEDen lyser nå konstant, også ved boot. Dårlig tegn. Koblet meg på serieporten og ble litt lettet over at det var action der. Kunne fint lese mac-adresse osv, og tilsynelatende også flash. Men det jeg leste ut fra flash er for det meste bare 0, med en og annen 1 bit i ny og ne. Absolutt ikke riktig. Og alle forsøk på å skrive noe annet feiler sjekksum-verifisering. Og booter selvsagt ikke. Etter noen forsøk med flash erase og write ble den faktisk enda sykere. Nå kommer den seg ikke vellykket gjennom en read_mac engang (og joda, jeg har prøvd med et par forskjellige USB TTL moduler, samt power fra USB eller fra intern forsyning. ingen forskjell): $ esptool.py -p /dev/ttyUSB3 read_mac esptool.py v3.3.1 Serial port /dev/ttyUSB3 Connecting.... Detecting chip type... Unsupported detection protocol, switching and trying again... Connecting... Detecting chip type... ESP8266 Chip is ESP8266EX Features: WiFi Crystal is 26MHz MAC: 34:94:54:7a:dd:ec Uploading stub... Running stub... Stub running... Traceback (most recent call last): File "/usr/local/bin/esptool.py", line 5399, in <module> _main() File "/usr/local/bin/esptool.py", line 5392, in _main main() File "/usr/local/bin/esptool.py", line 4824, in main operation_func(esp, args) File "/usr/local/bin/esptool.py", line 4222, in read_mac mac = esp.read_mac() ^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 1404, in read_mac mac0 = self.read_reg(self.ESP_OTP_MAC0) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 708, in read_reg val, data = self.command(self.ESP_READ_REG, struct.pack('<I', addr), timeout=timeout) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 468, in command p = self.read() ^^^^^^^^^^^ File "/usr/local/bin/esptool.py", line 413, in read return next(self._slip_reader) ^^^^^^^^^^^^^^^^^^^^^^^ StopIteration Jaja. Bortsett fra noen timer bortkastet på et prosjekt jeg ikke engang fikk testet ordenlig så er det jo bare mindre skapfyll. Problemet er at jeg kommer vel til å kjøpe en Plus Uni nå som jeg har et prosjekt å plugge den inn i. Og da er det bare tap. Lærte jeg noe? Håper det. Ikke brekk ut flere pinner enn du strengt tatt har tenkt å bruke i et prosjekt, fordi det kan være "kjekt å ha"

Kikket litt nøyere etter i z2m, og dimmerne annonserer da virkelig støtte for OTA-clusteret så vidt jeg kan se. Ser også at z2m har fått 0x36 versjonen som et "genOta" attributt (eneste dingsene jeg har med det, uten at jeg aner noe om hvorfor/hvordan): "genOta": { "attributes": { "currentFileVersion": 54 } } Veldig usikker på hvordan vi bør tolke den type info fra kundeservice. Mistenker at dimmerne støtter OTA helt fint, men at infrastrukturen med en firmware-server mangler.

Bummer. Det høres jo unødvendig herkete ut. Og dette hadde de ingen planer om å gjøre noe med? Jeg er litt usikker på om jeg gidder klage hvis det er slik at de må byttes fysisk for å fikse firmware... Ser at mine rapporterer "swBuildId": "2.9.2_r54" (i følge databasen til zigbee2mqtt). Klarer ikke helt matche 0x00000036 til noe. Hvor sjekker jeg denne versjonskoden? Ah, 0x36 = 54. Det er kanskje "_r54" da?

Vanskelig å si uten å vite hvilken versjon du har 😀 Du kjører update.sh scriptet. Evt leser det og utfører kommandoene som står der, evt med tilpasninger til din installasjon (f.eks. hvis du ikke bruker systemd). Se https://github.com/Koenkk/zigbee2mqtt/blob/master/update.sh for siste versjon. Prinsippet har vært det samme i lang tid, men jeg tror det er flikket litt på scriptet underveis.

Jeg har også sett det problemet der en gang i blant og er interessert i hva de kom fram til. Skjer heldigvis ikke ofte nok til at jeg ser det som noe stort problem. Mest irriterende ved at det gir automatiserings-skeptikerne vann på mølla 😀

Det er slik struct tm er spesifisert. tm_year er "year minus 1900". Se f.eks https://man7.org/linux/man-pages/man3/tm.3type.html