Ämne: IVT-protokoll (Rego 6xx)

[manicken84]

Tack!

Jag har nu, med hjälp av en logikanalysator, kommit fram till att displayenheten endast fungerar som ett användargränssnitt (UI). Inga inställningar lagras där. Det enda som skickas mellan enheterna är uppdateringar av displayinnehållet.

Det finns även en avbrottspinne från displayenheten till REGO600. Den används endast när någon trycker på en knapp, vilket gör att REGO600 då kan fråga vilken knapp som trycktes ned.

Och ja, jag vet att man kan fjärrstyra REGO600. Jag har nämligen gjort ett virtuellt gränssnitt i HTML och JavaScript som ser ut precis som min värmepumps originalinterface.

Problemet med fjärrstyrning via serviceporten är dock att den är ganska långsam. Dessutom kan den belasta REGO600 i onödan, och man kan inte långtrycka på knappar för att aktivera servicemenyn. Det spelar kanske ingen större roll ändå, eftersom mina senaste upptäckter tyder på att man sannolikt bara kan skriva till ett register för att aktivera servicemenyn.

Nu när jag vet mer har jag börjat fundera på en annan lösning. Man skulle kunna använda en ESP32 samt kanske en Raspberry Pi Pico som co-processor, då får man en "man in the middle" mellan displayenheten och REGO600. På så sätt skulle man få fullständig fjärrstyrning genom att skapa en helt virtuell display. Då skulle man dessutom kunna välja om man vill behålla den gamla displayen eller köra helt virtuellt.

Kanske lite off topic?

Ni kanske också undrar vad jag använder för att göra detta. Det är mitt egenutvecklade IoT-system som jag kallar DALHAL. För den som känner till dem kan det beskrivas som något i stil med Tasmota, ESPHome eller ESPEasy, men betydligt mer flexibelt, med en inbyggd skriptmotor och stöd för Home Assistant.

Egentligen är Home Assistant bara en enhetstyp eller modul, precis som min REGO600-implementation. Det finns även andra modultyper, till exempel en "Latching Relay"-typ som jag för närvarande använder för att styra ett bistabilt relä, vilket i sin tur styr EXT-ingången på REGO600.

Det som gör systemet annorlunda jämfört med många andra lösningar är att det inte är byggt kring Home Assistant eller enbart för att styra trådlösa strömbrytare. Det är i grunden utvecklat som en generell IoT-nod. Från början använde jag det bara för temperatur- och fuktighetssensorer, men den lösningen var väldigt begränsad. DALHAL föddes därför ur behovet av att kunna konfigurera enheten även efter att den hade flashats.

[Larsa H]

Wow, precis vad jag letade efter! Kan man ladda ner det någonstans och testa?

[manicken84]

Hej,
här har jag börjat på en github repository
https://github.com/manicken/rego600_reverseEngineer
där finns just det remote IF
men det interfacet är gammalt och jag har ingen backend som den kan köra mot för nuvarande
jag har nämligen mest hållit på med DALHAL, men ville ta en paus och då körde jag lite RE istället
den gamla backend är föråldrad, men i princip så fungerade den som en websocket <-> uart bridge så alla requests var i rådata format
det gav nämligen möjlighet att testa helt rått hur rego600:s service port fungerade utan att jag behövde vara nere i källaren.
Har tidigare hackat en Crouzet Millenium 3 för en EuroFire brännare och då körde jag också raw bridge men då endast som en raw tcp <-> serial bridge, det går säkert att göra här också men att hosta det via en websida är mycket mer flexibelt.
Jag undrar hur du hade tänkt att remote control skulle fungera i just ditt fall?
Min lösning kommer helt klart använda DALHAL

Jo förresten jag har kommit på hur man låser upp menyn till FABRIK access endast med hjälp av 3 kommandon

först skickar man 0x0004 till 0x7B95(regindex @ cmd 03) detta låser upp service meny access
sen skickar man 0x2c9c till 0x447(regindex @ cmd 03) detta navigerar meny till 5.12 version visning
sist skickar man 0x0008 till 0x7B95(regindex @ cmd 03) igen detta låser upp fabrik meny access

ska säga att jag har haft några problem med detta, kan vara så att jag skickar 9c2c istället för 2c9c, får återkomma med mer info
det är lite förvirrande med little endian osv får analysera koden bättre, fast det fungerar annars (konstigt)
men om man blir utelåst är det bara att starta om VP helt,
man kan också "manuellt" navigera till 5.12 via remote styrning och sen skicka det sista kommandot

Edit nu kom jag på, ibland av någon anledning så går det inte ens att komma in i service meny access då måste man power reset vp, jag ska undersöka för det måste finnas ett register som isåfall motverkar det, och kanske man kan göra mjukvaru reset.

[Larsa H]

Stort tack för repot, bra jobbat! Jag ska kolla om jag kan testa detta under helgen.

[manicken84]

Nu har jag bra koll på vilka misstag jag gjorde
hade missuppfattat vad big endian var (egentligen är det hur vi normalt skriver tal med bas 10, tycker det är en bra regel)
och den sista pusselbiten var att när man ska ändra access level så måste display timeout sättas till ett högt värde typ 0xFFFF (default 0x708)
för när timeout är noll så återställs alltid "requested" ny access level tillbaka till kund1
och sedan har jag också kommit på att man inte behöver mellanlanda på service access för att komma till fabrik

så nu är processen fortfarande tre writes
(alla register index är i förhållande till @cmd03):

1. skriv 0xFFFF till register index 0x436 (detta sätter timeout till max)
2. skriv 0x2C9C till register index 0x447 (väljer meny 5.12)
3. skriv 0x8 till register index 0x7b95 (sätter Fabrik Access)

0x7b95 kan ha följande värden, där det endast är fabrik som måste vara i meny 5.12 först för att aktiveras:
0x1 kund1
0x2 kund2
0x4 service
0x8 fabrik

hittade också ett annat register index, och det är för att tända bakgrundsbelysning
(det nollställs när timeout sker)
0x7B98 sätts till 0x1

jag har uppdaterat protokoll dokumenten också
och har börjat fylla i där nya register tillhör
tror jag kan säga vad register cmd 06/07 (kallas även register 1b61) är till för nu:

dem är högst troligt för intern states speciellt vad det gäller UI

edit. jo jag har även lagt till "disassembly listing" i repot för dem som vill titta på det

[manicken84]

Jag har nu tagit det ett steg längre och med hjälp av den fina JavaScript-baserade 8051-simulatorn js51 gjort första delen av en komplett simulerad REGO600-styrning.

Simulatorn körs direkt i webbläsaren och bygger på originalfirmware från REGO600.

Tanken är att simulera själva styrboxen och delar av hårdvaran som är ansluten till den. Hittills fungerar bland annat LCD-output och RTC, så klockan i displayen går och visas korrekt (mest för att det är roligt).

Det här blir ett väldigt användbart verktyg för fortsatt utveckling och analys av serviceporten. I simulatorn har jag direkt åtkomst till hela RAM-minnet, kan pausa CPU-exekveringen och ändra värden under körning utan att behöva gå via den begränsade serviceporten eller riskera riktig hårdvara.

Det gör det möjligt att testa hypoteser, följa programflöden och se exakt hur olika register och funktioner påverkar styrningen.
Det finns även möjligheter att gå vidare och modifiera originalmjukvaran. Tanken är bland annat att kunna ersätta vissa mindre använda servicekommandon (04-07) med egen maskinkod, exempelvis för att göra effektivare range-läsningar av sensorvärden och därmed få snabbare och mer flexibel automation.

Förhoppningsvis fortsätter hårdvaran att hålla många år till, men även om kompressorn skulle ge upp känns det som att den här tiden ändå är väl investerad. De flesta delar kan jag själv felsöka och serva, och nu finns dessutom möjligheten att förstå och vidareutveckla styrningen på en betydligt djupare nivå.


Jag har även börjat rita upp ett schema över REGO600-styrboxen. CPU-kortet är nu färdigdokumenterat, inklusive större delen av kringkretsarna. Värden på vissa ytmonterade kondensatorer saknas fortfarande, då de eventuellt måste mätas efter demontering för att få korrekta värden.

Nästa steg är att dokumentera POWER I/O-kortet, där bland annat anslutningarna mot relästyrningar finns.


Det verkar även som att hårdvaran är gemensam mellan flera modeller i REGO600-serien. Jag har verifierat att REGO634 (som jag införskaffade billigt för att underlätta reverse engineering) och min REGO637 har samma hårdvara, där skillnaden verkar ligga i mjukvaran.

Det innebär förhoppningsvis att mycket av arbetet med schema, simulator och firmwareanalys även kan vara relevant för andra REGO600-varianter. Om någon har en annan modell och vill bidra med information eller jämförelser är det givetvis intressant.

Simulatorn som körs direkt i webbläsaren finns på min github för dem som är intresserade att testa den
https://github.com/manicken/rego600_reverseEngineer/tree/main/80c552-sim

[Larsa H]

Snyggt jobbat!! 👏

[fulfisk]

Väldigt kul @manicken84. Har just lyckats att identifera dina fynd i Ghidra.

Som jag kan se på scheman pågår mycket kommunikation med peripherals över externa memory bussen. Min tanke ursprungligen var att upgradera hela styrningen mot något med Ethernet baserande på en FPGA kort som redan ligger kvar. Då har man möjligheter får att designa alla säkerhets-relevante ämnen direkt på chippen, plus slippar allt omkring mjukvarabaserande bitbanging och timing problemer.

To elaborate in english (swedish is not my mother tongue):
I might aid in building a digital twin of some peripherals (in HDL) such that we can trace correct functionality. This hardware model would then work on the "programmable chip" as well. However I would not put in much work in mimicking the 8051 behaviour or even cloning it, rather I would use the already existing CPU core (the intriguing norwegian ZPU architecture) running on that board (whose hardware design is open).
But as a dry dock simulation, a 8051 core might be useful in a first go (unfortunately the version I run is not opensourceable) to run the original binary against the virtual hardware to verify behaviour.

Maybe it would be possible to connect your simulator to the virtual hardware via websockets?

[manicken84]

Lite uppdateringar:
Simulatorn är nu mer än en simulator
https://elektronikforumet.com/forum/viewtopic.php?t=114689
Sammanfattat är det nu inbakat utvecklingsverktyg där man kan patcha firmware direkt med assembly

Ska rätta en grej, har kommit fram till efter kartläggning av mjukvaran att cmd 03 faktiskt skriver till flashminnet så den ska helst inte användas för att skriva till godtyckliga wrappade adresser eller register som inte tillhör settings, dock är det inte så stort problem då man skulle behöva skriva ungefär 16300 gånger till settings innan man eventuellt måste göra en fabriksåterställning av inställningar, (kan vara så att det görs automatiskt också inte verifierat)
Settings använder en så kallad journaling-log det innebär kort att gammal inställning raderas och den nya skrivs på oanvänd plats i minnet.
Men sen är det så att en sektor kan skrivas om ca 100000 gånger så rent teoretiskt skulle man kunna ändra en inställning en gång i sekunden i 51 år utan att flash förstörs och man måste byta till ett nytt.

Har börjat med att patcha firmware för att få ner tiden i main-loop detta för att få bättre respons på UART(service porten), sen har jag även patchat hela cmd hanteringen för att få plats med nya cmd:s som ska göra det möjligt att läsa av samtliga temperaturer och states i en request. Har även kartlagt hela front panel:s protokoll och har inskaffat i2c isolators så jag kommer troligtvis göra en virtuell skärm med hjälp av esp32 eller kanske en rpi pico och w5500.

edit. (fungerar bara på version 3.06)
för att göra fabriks meny åtkomst via service porten utan att behöva gå via cmd 03 som annars "sliter lite" på flash
cmd 0x07, regindex 0x28, värde 0xFFFF detta är timeout
cmd 0x07, regindex 0x39, värde 0x2c9c detta är meny 5.12
cmd 0x01, regindex 0x38, värde 0x08 sätter till fabriksnivå