Itho ecofan 3


HenkR

Golden Member

De communicatie gebeurt met een Itho Servicetool. Deze werkt op I2C.

Groet, Henk

Het is inderdaad I2C.
Ik heb ooit eens de signalen naar de ATMEL controller gevolgd en de RJ45 hangt inderdaad aan de I2C bus. Dacht niet dat ik activiteit op die bus zag dus ik ben niet zeker of de service tool I2C master is of niet.
Je zal het protocol ook moeten reverse-engineeren. Ik ben er in ieder geval geen stap verder mee geraakt.

(ik heb ondetussen wel al eens de controller print moeten herstellen en de kogellagers van de fans vervangen)

Kurt

Sine

Moderator

Aha, die dingen zijn dus te parametreren, dat is interessant.

Ik heb een tijdje terug zo'n unit opgehangen en daar een PWM print op geprikt waarmee je het ding zou moeten kunnen sturen, helaas reageert het ding niet op een pwm signaal. De informatie bij itho over dit soort toepassingen is erg beperkt.

Angaben sind wie immer ohne Gewähr.
HenkR

Golden Member

Ik heb nog even gezocht of ik de pinbezetting van de connector nog heb, maar helaas...

Groet, Henk

Ik heb het lang geleden eens geschetst. De RJ45 is de connector beneden en je ziet dat 2 signalen naar de SDA/SCL van de Atmel 169 gaan. De potmeters voor maximum/minimum toerental lijken ook op die signalen te zitten maar wel via een 5K6 weerstand. Het kan wel zijn dat de linkerzijde daarvan aan de Vcc hangt ... ik heb niet zo heel veel moeite gedaan om de signalen te volgen.

Als er iemand een service tool heeft kan je wel eens een poging ondernemen om de I2C traffic te sniffen.

Stijnos

Golden Member

De potmeters zitten hebben geen relatie met de i2c lijnen. Ze hangen gewoon aan vcc en de 5k6's zijn de pullups van i2c
De ecofan stuurt zelf vrijwel niks over i2c. Dit is enkel interessant voor een monteur voor bedrijfs gegevens en instellingen. Als eindgebruiker verkloot je alleen maar de werking van het algoritme hiermee.

interessant, ik zou graag m'n demandflow systeem in de domotica op willen nemen.

De software is hier te downloaden: http://zakelijk.ithodaalderop.nl/sites/default/files/documen...3-53-0.zip

Nu nog uitvogelen wat er van de pc->i2c interface verwacht wordt. :)

De software van itho gebruikt een compoort op 115200 baud, 8N1. Na het selecteren van een poort worden er twee bytes naartoe geschreven; 0x10 en 0x16.

Ik ga eens een transparante usb -> i2c converter opzoeken en kijken of ik iets aan de lijn krijg hiermee :)

Hallo allen,

Ben benieuwd of jullie hier nog verder mee zijn gekomen. Ultieme doel zou zijn om het systeem te kunnen koppelen op een domotica controller (zoals Domotica). Gaat in eerste instantie om het uitlezen, maar daarna kunnen besturen zou mooi zijn.

Tronix

Ik heb een Itho HRU WTW balansventilatie, met zo'n zelfde rj45 COM port, en die wou ik ook eens uitlezen :)
Maar goed. Ik heb de servicetool van Itho gedownload en aan de gang gekregen, maar deze kan de machine niet vinden.

Weet iemand hoe die kabel van rj45 naar serieel in elkaar zit? Ik heb verschillende pinouts geprobeerd, maar geen enkele werkte. Ook de null modem variant niet.

OVerigens, ik vermoed dat dezelfde poort op alle Itho producten zit, mijn CV ketel heeft ook zo'n ding en in de broncode van de service tool staan verschillende parameters voor alle producten.

Groet!
Aart

Weet iemand hoe die kabel van rj45 naar serieel in elkaar zit? Ik heb verschillende pinouts geprobeerd, maar geen enkele werkte. Ook de null modem variant niet.

Logisch, er zit nog een AVR tussen, die doet serieel -> I2C en misschien nog wat extra.

It's the rule that you live by and die for It's the one thing you can't deny Even though you don't know what the price is. It is justified.

Was ik al bang voor. Helaas weet ik heel weinig van dit soort dingen.

Heeft iemand die setup al voor elkaar? Als ik zou gaan prutsen zou ik zo iets kopen: https://www.antratek.nl/usb-to-i2c-module en dan de pinout proberen uit te vogelen.

Zit ik op de goede weg? Is iemand al wat verder?

Stijnos

Golden Member

je kan dat zelf niet maken.
Er zit een actieve omzetter tussen, die van protocol x naar protocol y gaat.
de RJ45 connector is geen uart maar I2C

Zou Itho vragen een optie kunnen zijn? Dit lijkt me geen geheime informatie en zal de waarde van het product zelfs verhogen als het aan domotica gekoppeld kan worden.

Shiptronic

Golden Member

Wie de vraag stelt, zal met het antwoord moeten leren leven.
Stijnos

Golden Member

Op 11 december 2018 18:27:06 schreef rustyx:
Zou Itho vragen een optie kunnen zijn? Dit lijkt me geen geheime informatie en zal de waarde van het product zelfs verhogen als het aan domotica gekoppeld kan worden.

Zodat iedereen zijn parameters gaat verkloten en er klachten komen over de goede werking van het systeem? Daar hebben ze geen baat bij. En ik verwacht niet dat die domotica zo'n gtote doelgroep is en daar richten ze zich zelf ook op met hun spider systeem

Op 18 september 2015 00:03:31 schreef Zwaskin:
interessant, ik zou graag m'n demandflow systeem in de domotica op willen nemen.

De software is hier te downloaden:

Nu nog uitvogelen wat er van de pc->i2c interface verwacht wordt. :)

De interface van de dongle is geen RS485 maar een gewone I2C. Je kan het zien van de directe connecties met de AT168P I2C pins.

Inderdaad kon ik na een paar Buspirate sessies wel wat informatie verzamelen en een succesvolle connectie maken (gebruik zelf ESP32, maar Atmega moet ook kunnen).

De poort is COM, 115200-N-1.

Serieel protocol (richting PC):

0x10, 0x16 - ping (reply 0x10, 0x16)
0x10, 2 - packet start
0x10, 3 - packet end
0x10, 0x10 - data byte 0x10

I2C protocol (richting Itho):

I2C master 100kHz + I2C slave op adres 0x40 (0x80 W)

Elke packet heeft een controlegetal byte aan het eind, checksum = -(sum van alle bytes).
Eerste byte is bestemming (0x82 = Itho board)
Tweede byte is reply adres (0x80 = dongle)
enz.

Opvragen node ID:
82 80 90 E0 04 00 8A

Voorbeeld antw.:
80 82 90 E0 01 12 00 01 00 03 12 0B 00 00 00 FF FF FF FF FF FF FF FF 00 62

03 = HRU, 12 0B = versie/revisie.

Opvragen status:
82 80 A4 01 04 00 55

Voorbeeld antw.:
80 82 A4 01 01 25 00 00 03 9C 03 9E 03 98 03 EB 03 EB 09 09 09 8A 00 09 09 09 8A 00 00 0B B8 01 00 00 00 B1 79 00 00 00 00 10 95 9F

De temperaturen zijn de bytes 09 09 09 8A, dat zijn 23.13 C en 24.42 C respectivelijk (*.01 waarden dus).

De eerste 00 00 is de "vraag". Het gaat van 0 voor stand "1" tot E8 03 (100.0?) voor stand "3".

Helaas was mijn HRU-ecofan te "nieuw" voor deze software (software ondersteunt HRU t/m rev. 10 en die van mij was rev. 11) en kon ik niet verder. Dus als er een nieuwere versie is dan probeer ik die graag.

PS. Op dezelfde bus is er ook RF verkeer te zien (naar 82 van 60). Door die berichten na te spelen kon ik de stand (1/2/3) bedienen.

Shiptronic

Golden Member

Wie de vraag stelt, zal met het antwoord moeten leren leven.

Ik heb geen ecofan3, maar wel een Itho warmtepomp WPU-5i waarvan ik verwacht dat hetzelfde I2C (en mogelijk protocol) wordt gebruikt op de RJ45 aansluiting.

Waar ik aan denk is om een Bus Pirate te gebruiken om USB naar RJ45/I2C te brengen en via een laptop de service tool te kunnen gebruiken. Vervolgens zou ik dit moeten kunnen sniffen om het protocol te onderzoeken.

Ik heb geen ervaring met I2C of Bus Pirate, maar klinkt het als een geldig plan of zijn er andere suggesties?

Op 18 april 2019 22:16:44 schreef forkboy:
Waar ik aan denk is om een Bus Pirate te gebruiken om USB naar RJ45/I2C te brengen en via een laptop de service tool te kunnen gebruiken. Vervolgens zou ik dit moeten kunnen sniffen om het protocol te onderzoeken.

Ik heb geen ervaring met I2C of Bus Pirate, maar klinkt het als een geldig plan of zijn er andere suggesties?

BusPirate is een sniffer en een master, maar helaas geen slave. Er moet wel een I2C slave op de bus zitten om de antwoorden te kunnen ontvangen. Zonder een ACK op 0x80 wordt er niks teruggestuurd.

Een atmega328p (arduino nano) kan als een simpele I2C slave geprogrammeerd worden. Zelf gebruik ik ESP32 devkit (+logic level shifter want ESP is een 3,3V apparaat), zo is die gelijk aan WiFi gekoppeld. Als ik de tijd heb dan post ik mijn code op github (moet eerst schoongemaakt worden). Ik kon daar zelfs de sniff functionaliteit implementeren en heb de buspirate nu niet meer nodig.

Pas op de bedrading op die RJ45 poort - er zit ergens +15V tussen.

Volgens mij zat het er zo uit:
2 - SCL
3 - GND
4 - GND
5 - +15V
7 - SDA

Stijnos

Golden Member

Succes met de warmtepomp. Die heeft heeeeeeel veel log data.
Mijn complimenten voor het gereverse engineren rustyx.
Maar pas op. Ga zeker bij de warmtepomp niks aanpassen, want gegarandeerd dat je ieta omzeep helpt

Inmiddels ben ik wat onderzoek verder. Ik heb de servicetool voor warmtepompen gedownload en deze is eenvoudig te reversen. Het is een in VB.NET geschreven tool.

Hieruit krijg ik vervolgens een schat aan informatie over het protocol. Ik kan ook communicatie simuleren en zo de servicetool gebruiken zonder dat die echt verbonden is. Wel zie ik in de code de communicatie zoals geschreven vanuit de PC en daar zit nog die omvormer van USB naar I2C tussen.

@rustyx. Nu snap ik dit nog niet helemaal. Ik zou denken dat de USB/I2C omvormer (Itho noemt hem zelf SVM-USB) een master is op de I2C bus en de ecofan of warmtepomp hier de slave. Dit omdat de communicatie vanuit I2C alleen vanuit een master gestart kan worden en vanuit de PC worden de opdrachten verstuurd (zoals ping, maar ook ophalen Node identificatie, settings, log enzovoort)

Ik zou dan toch de buspirate rechtstreeks op de WPU kunnen aansluiten en dan commando's versturen ala hoe dat anders vanuit de SVM-USB gebeurd? @rustix: Jij lijkt anders te zeggen omdat er een slave op adres 0x80 moet zitten. De WPU/HCU is 0x82.

@Stijnos. Ik zie inderdaad een hele berg instellingen en log gegevens. Mijn intentie is om niets aan te passen, maar ik moet dan natuurlijk wel het protocol goed begrijpen... Eerst maar eens beginnen met de Autotemp. Die gebruikt dezelfde aansluiting.

@Rustyx, Na een buspirate sessie denk ik dat ik het inmiddels al begrijp. De bus is een multi-master en multi-slave. Het protocol zorgt voor de adressering en de dongle (SVM-USB) reageert op de 0x80 packets. Ik kan de door jou genoemde berichten ook vinden in de servicetool code.

Byte 3 en 4 noemen ze de messageclass en byte 5 is de messagetype. Hierna komt het laatste 6e byte van de header en dat is de data lengte van de variabele. Hierna variabele data met aan het einde de checksum.

Ik ga aan de slag met een slave maken; ik heb nog een raspberry Pi die ik kan gebruiken.

@Rustyx, ik heb wel interesse in de broncode die je hebt gebruikt. Dit ondanks dat het een andere controller is die je gebruikt en van mij hoeft de code niet opgeschoond te zijn...

Ik kom met mijn eerste versie van een slave niet echt verder. Ik vermoed dat het komt omdat de slave geen communicatie kan openen. Ik kom dan ook in een setup met autotemp (master), buspirate als sniffer en raspberry pi (slave) niet de data tegen die ik vanuit de raspberry pi probeer te versturen. Ik zie wel data op de I2C bus vanaf adressen 0x82 en 0x60.

Mijn code (niet de fraaiste) heb ik hier neergezet: https://github.com/ootjersb/pislave

Ik blijf maar spammen, maar het is me nu gelukt om wel verder te komen. Ik draai nu een I2C slave op 0x80 en stuur separaat via een I2C master commando's. De responses worden dan netjes door de slave geACKt.

@Rustyx ik heb nog even gekeken naar jou vraag aangaande het antwoord op het A401 bericht. Hier vroeg je je af hoe je de data moet interpreteren.

Nu wordt dit geregeld door het bericht A400. Dit bericht wordt verzonden als:
[0x82 0x80 0xA4 0x00 0x04 0x00 0x56]

Op dit bericht komt voor iedere waarde een byte terug die het datatype aangeeft. In jouw geval gaat het om de allereerste waarde als ik het goed begrijp. Byte 7 van het response bericht A400 geeft dan het type aan.
Bij mijn warmtepomp kwam ik deze typen tegen:
0x00 of 0x0C: Byte (1 byte)
0x92 Signed int (2 bytes)
0x12 Decimaal getal Unsigned int / 100 (2 bytes)
0x10 Unsigned int (2 bytes)

De temperaturen worden doorgaans als 0x12 doorgegeven. Als je een ander type tegenkomt kan ik die wel opzoeken hoe de codering werkt (type 0x11 zou jouw suggestie ofwel unsigned int / 10 zijn).