Övervakning av Telldus Core/Svc (fr. tråd "Slutter å hente..

[latis]

Den senaste drivrutinen ska klara av tdClose() utan att krascha (vilket inte den tidigare gör). Det löser ju inte grundproblemet men är ju en väg för omregistrering.

Jag byggde en heartbeat-funktion för tdSetName även i Switch King förra veckan - mest för att testa - men när jag ska köra tdUnregisterCallback så returnerar aldrig metoden från Telldus Core-anropet och blir kvar i evighet.
Då visste jag dock inte om att nya drivrutinen skulle klara tdClose(), så jag stoppade försöken där. Att tdClose() ska fungera i nya drivrutinen fick jag reda på i fredags.
Det är möjligt att tdClose() följt av en tdInit() räcker - dvs jag måste inte köra tdUnregisterCallback. Man kan tycka att tdClose() bör sopa undan allt och göra det fritt fram för nyregistrering.

Är detta något ni kan bygga in i SK för att tillfälligt lösa problemet menar du? Göra någon version vi som har problem kan få testa?

[Martin]

Är detta något ni kan bygga in i SK för att tillfälligt lösa problemet menar du? Göra någon version vi som har problem kan få testa?

Beror på om det löser sig med tdClose()-problemet som nämndes. Det kommer isf inte att bli någon officiell version eftersom det kräver en drivrutin som Telldus inte har släppt offentligt.
Dessutom blir versionen baserad på antaganden - ingen av oss som jobbar med Switch King har problemet med tappade anslutningar. Jag hade tidigare problemet (men inte längre) och Tomas har aldrig haft det, vilket gör det oerhört svårt att bekräfta om det öht löser något, så vi får räkna med er hjälp där

[krambriw]

Att tdClose() ska fungera i nya drivrutinen fick jag reda på i fredags.

Jag kör ju nu med den senaste drivrutinen om det är den som ni länkar till och där fungerar tdClose() inte. Däremot verkar man kunna göra tdInit() hur många gånger som helst.

Motsvarande enkla test borde kunna göras i C# så att ni kan verifiera att ni får samma resultat som jag får med Python.

mvh

Code: Select all

from ctypes import windll
dll = windll.LoadLibrary("TelldusCore.dll")
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdClose()
79962352
dll.tdClose()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
WindowsError: exception: access violation reading 0x00000004
dll.tdInit()
79962352
dll.tdClose()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
WindowsError: exception: access violation reading 0x00000004

[Martin]

Jag kör ju nu med den senaste drivrutinen om det är den som ni länkar till och där fungerar tdClose() inte. Däremot verkar man kunna göra tdInit() hur många gånger som helst.

Motsvarande enkla test borde kunna göras i C# så att ni kan verifiera att ni får samma resultat som jag får med Python.

Det är den drivrutin som finns först i denna tråd som avses. Jag ska försöka testa och se vad som händer med en rad tdInit(), tdClose().

[latis]

Undrar om någon skulle vilja göra lite tester och se om ni kan få fram problemet.

Jag kör min telldus på en server jag har, där kör jag även min väderstation samt ett program som heter wxsim (framställer väderprognoser). WxSim tar 100% cpu och massor av andra resurser vid insamladet av data från olika METARS. Av någon anledning fick jag för mig nu att detta kan ställa till det. Kan någon försöka köra typ seti@home eller annan mjukvara som slukar all datorkapacitet och se om ni kan få fram problemet med "borttappade" termometrar? Slog precis upp fjärrskrivbordet och såg att den slutat få temper från och med 16:40 (precis när mitt insamlande börjar). Jag kan desvärre inte testa att stänga av detta då många använder min data i nuläget och är beroende på färsk information och jag har ingen annan server att testa på.

Bara en idé jag fick, kanske är det så att processen inte väntar särskilt länge på inkommande info, och får den inte svar inom en viss tid så bryts kopplingen mellan servicarna? Jag har testat att ge:
Telldus Service.exe och SwitchKing Service Host.exe lite ökad prioritet. Hittar inga andra tjänster som har med TD eller SK att göra. Får se om detta ändrar något i mitt problem.

[Martin]

Det ska finnas någon form av Timeout i kommunikationen mellan Telldus Service och Telldus Core, så där är du rätt ute.
Dock så ska man ha skruvat upp timeoutgränsen i de senaste versionerna av drivrutinerna. När det gäller Switch King så går denna kommunikation också i en egen tråd för att servern i sig ska kunna vara fullt belastad utan att påverka timeouten, men det är klart - om det kräver mycket processorkraft inne i Telldus Core eller Telldus Service så är det ju kanske så att det blir någon intern timeout...

[latis]

Värt att testa kanske, har du bra kontakt med Telldus så kan du ju meddela dem teorin.
Nu kör jag på de gamla eftersom jag tyckte de nya gav mer problem, dock hade det nog med dålig USB att göra.

Ska köra in de nya drivrutinerna ikväll och se om det blir någon bättring.

[latis]

Nu har jag problemet aktivt igen här, min fix med prioritering funkade således inte.

Verkar som att det endast är duo'ns mottagning som stryker med dock. Kan fortfarande styra lampor, och eventghost får svar på förfrågningar:
Switchking: Device OFF: heartbeat
TellStickDuo.heartbeat.OFF 'selflearning-switch:nexa.67'

Fattar inte detta riktigt, är det så ni andra har det också? Förresten, mina andra datakällor funkar (hämtar in solinstrålning från min väderstation via en online textfil utan problem).

Hmm, kollade igenom lite och blev nu riktigt konfunderad... Switchking's datakällaflik visar senaste värde kl 18:58. Dock om jag kollar i händelseloggen så visar denna fortfarande värden. Den har heller inte uppdaterat värdet som att det vore för gammalt (dock mer än 30 minuter gammalt nu som är min gräns), det visar heller inte samma värde som händelseloggen.

Omstart av switchking klienten avhjälpte problemet denna gång. Detta har jag inte sett tidigare. Precis som att klienten slutade uppdatera datakällan (gällde faktiskt alla datakällor denna gången).

Nu vet jag inte om min fix fungerar eller inte, eftersom det endast verkar ha varit ett problem med switchking klienten denna gång. (kör V3 både server och klient).

[Martin]

Att tdClose() ska fungera i nya drivrutinen fick jag reda på i fredags.

Jag kör ju nu med den senaste drivrutinen om det är den som ni länkar till och där fungerar tdClose() inte. Däremot verkar man kunna göra tdInit() hur många gånger som helst.

Motsvarande enkla test borde kunna göras i C# så att ni kan verifiera att ni får samma resultat som jag får med Python.

mvh

Code: Select all

from ctypes import windll
dll = windll.LoadLibrary("TelldusCore.dll")
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdInit()
79962352
dll.tdClose()
79962352
dll.tdClose()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
WindowsError: exception: access violation reading 0x00000004
dll.tdInit()
79962352
dll.tdClose()
Traceback (most recent call last):
  File "<input>", line 1, in <module>
WindowsError: exception: access violation reading 0x00000004

Jag kan faktiskt köra detta utan att det smäller. Däremot verkar tdInit() och tdClose() smälla i ett senare skede - en avregistrering och omregistrering i kombination med tdClose() och tdInit() ger krasch.

[krambriw]

Däremot verkar tdInit() och tdClose() i ett senare - en avregistrering och omregistrering i kombination med tdClose() och tdInit() ger krasch.

Då blir det nog tyvärr samma problem även med C#. Om felet uppträder krävs nog att man genomlöper samtliga av följande steg för att göra en korrekt återanslutning:

- avregistrera samtliga callback's
- (eventuellt nollställa handles)
- stänga biblioteket med tdClose()
- (eventuellt liten paus)
- initiera biblioteket med tdInit()
- registrera nya callback's

Vad tror du?

Vad skulle man kunna tänka sig för förbättring på Telldus sidan för att få bukt på detta?

En ide:
- ytterligare ett callback introduceras för heartbeats
- en ny metod tdReConnect...
eller helt enkelt fixa så att tdInit och tdClose fungerar ihop med omregistrering av callback's

mvh