Ämne: Första månadens problem med RCU-10

[sij]

Första månadens problem med RCU-10

Att koppla in RCU-10 rent fysiskt till 1230-10 var inget problem.

Att få kontakt mellan min dator och RCU:n var ett engångsproblem med flera moment.

Att få RCU:n att tillförlitligt leverera data är ett olöst och fortgående problem.


Anslutning i nätverket.

RCU:n var märkt med MAC-ID 00:30:11:FB:09:55.
IP-adressen skall enligt beskrivningen vara 10.200.1.X där X ska vara sista siffran i MAC-ID.
I mitt fall var X inte lika med 5, inte heller lika med 55, utan lika med 85. Att hexadecimala 55
i MAC-ID skulle göras om till decimalt 85 står inte speciellt uttalat i instruktionen. Det tog mig en stund med Ethereal att hitta det. Den förinställda IP-adressen för min RCU var således 10.200.1.85

NIBE skickar med ett program på CD som ska kunna gå ut på nätverket och känna igen vilka RCU-enheter som finns anslutna. Åtminstone för mig fungerade detta först sedan jag gett min dator en adress av typen 10.200.1.Y, dvs  i samma subnät som RCU:n redan fanns i. Jag kunde alltså inte hämta upp RCU:n från mitt nätverk med adresser av typen 192.168.97.1 - 192.168.97.254.

Så med RCU:n kopplad med en korsad kabel rygg mot rygg mot en lös dator som jag tillfälligt gav adressen 10.200.1.50 kunde jag surfa till webbservern i RCU:n på 10.200.1.85. På en inställningssida kunde jag ändra RCU:n adressuppgifter till önskad IP = 192.168.97.185, önskad mask, mm. Då tappade jag naturligtvis kontakten från datorn med den tillfälliga adressen, men kunde istället koppla in RCU:n på nätverket och surfa till den därifrån.

På nätverket har jag blandade ethernet-enheter för 100Mbit/s och 1Gbit/s. Switcharna har autosense och ställer om sig för 1000/100/10 efter behov. RCU:n och switchen blev överens om 100 Mbit/s.


Hämta data från RCU:n

Jag surfade till RCU:n och beställde loggning av alla parametrar med 1 minuts intervall. Minnet i RCU:n ska då räcka några dagar innan gamla data blir överskrivna av nya. Att spara data i RCU:ns minne tycks fungera. På en av RCU:ns webbsidor kan man klicka på en knapp och få loggade data överförda som en textfil med semikolonseparerade data. Jag vill logga automatiskt och ofta nog för att inte tappa data. Jag satte upp ett cron-skript innehållande kommandot

   wget --output-document=$parmloggfil \
        --tries=1  --wait=$Sleeptime \
        --no-verbose  --append-output=$Downloadlog \
        http://loggrdr:loggrdrpw@192.168.97.185/cgi-bin/log.csv?parlog

(Jag är fortfarande nybörjare i Linux-världen. Är det något på tok med kommandot?)

En normalt överförd loggfil upptar från drygt 1 MB upp till drygt 2 MB. Oftast fungerar det bra, men då och då överförs bara något hundratal bytes (första delen av första raden, den med kolumnöverskrifter). Ibland får man inget data alls och då har webservern i RCU:n hängt sig så RCU:n är helt oåtkomlig. Det enda sättet jag hittills känner att komma igång igen är att slå av dess matningsspänning och slå till igen. I samband med det tappar man en del lagrad data.

En gång i början noterade jag att wget har en egen funktion för att göra förnyade överföring vid fel. Annars tycks wget acceptera att blocket är kort eller att kontakten är bruten. I mitt skript gör jag två omförsök med fem minuters mellanrum. Om felet var ”kort block” händet det att det fungerar efter en stund.

Mitt intryck är att datorn/webservern i RCU:n har ett överbelastningsproblem. Frågar jag ofta efter överföring så hänger sig RCU:n ofta. Frågar jag mindre ofta hänger den sig mindre ofta men uppskattningsvis lika stor andel av förfrågningarna. Under någon vecka körde jag med två avfrågningar (en larmdata- och en parameterdata-) i timmen och fick starta om den ungefär en gång per dygn. Jag har också dragit ner antalet loggade punkter från 90 till ca 50, men har inget klart intryck av förbättring. Senaste veckan har jag kört RCU:n rygg mot rygg mot en separat nätverksutgång på datorn ifråga, så att jag kunnat styra ner ethernet-överföringen från 100 Mbit/s till 10 Mbit/s. Möjligen har antalet omstarter varit något lägre.

Har någon annan kört RCU:n på samma eller liknande sätt - med eller utan liknande problem?

/ingemar (sij)

[Gla]

Hej Ingemar!

Jag har funderat på att köpa en RCU-10 i en månad nu, men ej kommit till skott.
Efter din berättelse så känns det inte så överhängande bråttom att göra en beställnig.
Du får gärna lämna rapporter på hur det går och hur du avhjälper felen.

/Gla

[MatteD]

Hej Ingemar

Det kanske skulle fungera bättre om du kommunicerar direkt med NIBE styrsytemet verkar vara RS485 kommunikation. Det borde gå bra att lyssna på trafiken till RCU-10 och få fram komandona om du har en RS-485 till USB eller RS-232 omvandlare?

Jag tror många andra vore intresserade av det också.
/Matte D

[Dataankan]

Matte D - Du har rätt. Fler är intresserade av protokollet.

Ingen som känner till protokollet ännu eller som har möjligheten att lyssna av trafiken mellan RCU-10 och Styrsystemet?

[fkbo]

Jag har loggat lite RS-485 trafik men jag har ingen RCU-10 så det har inte givit någåt ännu. Skulle vara kul om någon med en RCU-10 kunde logga lite och se vad RCUn svarar på pannans request 0x5C.

[sij]

Hej alla!

Det kom ett mejl...

Nej, jag har inte varit aktiv på forumet på länge så det kanske är på plats med en uppföljning till mitt inledande inlägg

Jag var under våren och försommaren 2006 i kontakt med NIBE några gånger, pratade med människor som i telefon var idel välvilja, tyckte problemet var deras. Jag fick småningom en RCU med något uppgraderad programvara. Den löste inte problemet. NIBE har tydligen ingen koll själva på programvaran utan har lagt ut jobbet på någon underleverantör. De lovade återkomma men har sedan aldrig hört av sig.

Jag skaffade en 485-till-USB konverter men har inte kommit till skott med att logga 485-trafiken. Jag håller fortfarande på att ta mig in i Linux-världen och känner att jag vill inte nedlåta mig att koppla upp en windowsdator och återgå till Visual Basic för detta.

Mitt skript som hämtar RCU-data via dess webbgränssnitt till min filserver fungerar bra och skickar mejl till mig efter varje hämtning från RCU:n, så jag märker meddetsamma när webbgränssnittet har hängt sig. RCU:ns datainsamling från värmepumpen fortsätter även om gränssnittet har hängt sig. Jag tappar en stunds data varje gång jag rycker strömmen till RCU:n för att få den att starta om. Om jag är bortrest kan det bli många dagars borttappat eftersom buffertminnet i RCU:n är begränsat och återanvänds efterhand.

Långsiktigt är det min avsikt att hacka upp protokollet på 485-ledningen och därefter kunna prata med värmepumpen själv utan att ha RCU:n med i svängen. Lite hjälp av någon linuxkompetent skulle säkert få upp prioriteten och farten på projektet i min ände.

mvh

/ingemar

[Heddan]

Om du inte gör några hämtningar alls går den stabilt då?

Du säger att den verkar lite stabilare vid 10Mbit/s, är det hel(FDx) eller halv duplex(HDx). Varför jag frågar är för att jag vet att autosense kan ställa till stora problem, och autosense bara fungerar om båda parterna har det aktiverat. T.ex. om den ena parten är hårt ställd på 100FDx och den andra har autosense påslaget så kommer den bara att ställa sig i 100HDx. Och då blir det många tappade paket osv...bara en tanke. Men det borde inte få webservern att hänga sig men man vet aldrig...

[sij]

Hej heddan!

Det där med 10 Mbit eller 100 Mbit var nog bara ett tillfälligt tyckande de första veckorna. Jag körde under flera månader på en dedicerad 10 Mbit linje och flyttade senare över RCU:n igen till mitt vanliga nätverk (där switcharna inte är låsbara utan anpassar sig individuellt till varje ansluten ledning, dvs 100 Mbit mot RCU:n, 1000 Mbit mot filservern).

De skillnader jag tyckte mig kunna se under första tidens labbande kunde jag inte känna igen.

Däremot är det helt klart att om jag från servern ofta frågar RCU:n efter data så inträffar felet oftare/tidigare än om jag mera sällan skickar avfrågningen till RCU:n.

Om sannolikheten för fel är beroende eller oberoende av hur många gånger det gått rätt sedan senaste omstart? Jag har inga starka belägg för någondera.

Numera frågar jag RCU:n tre gånger per dygn, vilket ger mig hyfsad chans att starta om den innan den skriver över första hälften sin databuffert. Då kan den ofta fungera i några veckor i sträck.

Med det val av loggade parametrar jag gjort så innehåller en helt fylld databuffert data för ca 7 dygn och detta överförs i textform som drygt 2 Mbytes. Med intervall av ca 3½ dygn slängs den äldsta hälften av buffertinnehållet och överföringsmängden blir drygt 1 Mbytes. Därefter läggs nya data in efterhand tills den övre nivån igen uppnås.

Om jag tror på min egen tolkning ovan så borde jag kunna öka avfrågningsintervallen från 8 timmar till 16 eller 24 och kunna få längre perioder med funktion.

Du frågar: om jag inte hämtar data alls? Svar: vet ej. Det kanske kan vara så att webbsnittet håller sig levande mycket längre, kanske så länge som någon orkar observera. Men det har jag inte kommit mig för att försöka eftersom jag då skulle tappa en mängd data.

/ingemar

[fkbo]

Här är en länk till företaget som har utvecklat RCU10 åt NIBE: IntelliCom

[overlander]

Verkar ju lysande kanske det går att komma undan lite billigare än 10000 då.

[fkbo]

Jag har faktiskt fått svar från pannan men det säger inte så mycket. Jag skickar svaret 0xF3 på pannans 0x5C. Jag får då ytterligare data från pannan som kan se ut enligt följande (efter lite avkodning) (Hex):

03 24 11 00 05 00 0E 01 06 01 1E 00 07 01 13 00 08 01 04 23

Det verkar vara någon typ av uppräkning av register eller liknande. Det kommer index (understruket) som ökar upp till 0x2F och sedan börjar det om.

Någon mer därute som gjort något försök att logga?