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

[sege]

Jag måste få till någon automatisk omstart av SW under Linux nu när den tappar telldusd för det gör den två gånger om dagen ungefär. Varje gång blir det knas och kaos.

Hur gör jag? REST-anrop som kollar om det är 'felrapport'-nuffra på en givare och kör en kill på SW? Stänger en kill ner SW snyggt? REST-anrop för att stänga ner annars, finns det?

[sege]

Jag gjorde så här nu:

Code: Select all

sege@hail:~/bin$ cat check_sw.sh 
#!/bin/bash

WORKS=0
for i in 4 5 9; do
	SENSORVALUE=`cat /mnt/SwitchKing/datasource_$i.txt`

	if [[ $SENSORVALUE == "0,0" ]]; then
		WORKS=`echo $WORKS+1 | bc`
	fi
done

if [[ $WORKS -ge 2 ]]; then
	/usr/bin/pkill mono
	echo "Restarting SwitchKing"
fi

Fantastiskt vackert, om två sensorer av tre failar starta om SW, verkar fungera. Körs i cron var femte minut. Fulscript is da shit.

[latis]

De drivrutinerna som står i OP gjorde iaf allting värre för mig. När det dör nu, löses det inte genom att starta om tjänster längre, måste dra ur Duon, starta om tjänster och ibland till och med starta om hela datorn.

[latis]

Det är lite märkligt detta...

Ibland funkar det att starta om alla 5 switchking tjänster för att tempen ska hoppa igång igen. Men ibland räcker det inte, då måste datorn startas om.

Lösningen som någon hade med Evenghost som känner av en HeartBeat device funkar heller inte för mig, den känner aldrig av att det är fel.

Undrar om jag har något annat problem, min klarar sig nu mer inte mer än ett par timmar i stöten, något som är lite ohållbart då min värme i huset är tänkt att baseras på tempen som kommer in till SK. (Har byggt en egen shunt-styrning som utgår från innetempen).

Tråkigt att behöva gå tillbaka till 1-wire när man trodde det funka trådlöst, känns som Telldus famlar lite i mörker eftersom de efter månader inte kunna åtgärda denna ganska allvarliga buggen.

Hoppas på en snar fix!

[krambriw]

Lösningen som någon hade med Evenghost som känner av en HeartBeat device funkar heller inte för mig, den känner aldrig av att det är fel.

Lite oklart definierat vad det är du använder för program förutom SK. Av ovanstående antar jag att du även kör EG, eller? I så fall betyder det att EG uppenbarligen är nöjd, dvs EG har inga problem med kontakten till Telldus Service. Om EG detekterar problem, så återstartas Telldus Service om du använder den plugin jag la upp ovan i tidigare post. Däremot upptäcker den inte om SK tappat kontakten.

1) Kör du EG också?
2) När det är fel, ser du händelser komma in i EG men inte i SK?

Jag noterade själv idag för första gången detta att händelser inte visades i SK men det fungerade i EG. Lösningen var att starta om SK's tjänster. Jag rörde aldrig Telldus Service.

mvh

[Isaksson]

Skulle vara intressant om någon av er som har problemet skulle kunna testa att installera tex 2008 R2 eller server 2012 eller varför inte windows 8 för att se om problemet kvarstår vid byte av operativ, eller om det helt enkelt är hårdvaran?
Jag skulle utan problem kunna testa detta om det nu inte vore för att jag själv inte lyckas få stopp på min signaler
Jag har testat med windows 7 och 2008 R2 med två olika Duo och har testat med magnetbrytare, ir deckare, temperatur givare, drog även igång en tempsensor som legat här väldigt många år (stödjs ej av telldus) men signalen får jag ju in i duo endå.
Men vad jag än gör så vill det bara fungera.

[krambriw]

Nu har det hänt, det jag väntat på. Igår såg jag för första gången att händelser inte trillade in till samtliga klienter som var igång och anslutna (EG, SK och TC). Först var det SK som inte fick dessa tidigare på dagen men efter omstart av SK's tjänster var alla igång igen. Senare på kvällen så kom inga händelser in i EG längre, däremot fortsatte dom att komma in i SK och i TC!!!

I en av Telldus debug loggar syns detta men det är väldigt sparsamt med detaljer. Telldus Service tappar helt enkelt bort en klient anslutning och detta sker utan att klienten får något meddelande om detta. Inte heller görs något försök från Telldus Service att reparera anslutningen (och det kanske inte heller är möjligt).

Jag tror det kommer behövas någon form av heartbeat callback event från Telldus Service så att klienterna kan återansluta om anslutningen kopplas ner.

När det här felet har uppträtt räcker det inte heller med att starta om Telldus Service, den är ju faktiskt redan igång och fungerar normalt. Det är klienten som måste återansluta själv.

Den temporära lösningen som jag gjorde i EG med att byta namn på en enhet räcker bara för att kontrollera att Telldus Service är igång men täcker inte in detta fall. Jag måste komplettera med att övervaka att jag också får in ett callback för Change Event när jag byter namn på enheten. Om detta inte kommer är det alltså dags att återansluta.

Oavsett så är det i Telldus Service som den slutgiltiga lösningen måste komma, det går ju inte att klientanslutningar bara tappas bort. Det måste finnas en bättre lösning så att dessa kan hållas vid liv och etableras på nytt om dom trots allt skulle fallera.

mvh

Från telldus_service_debug:

Code: Select all

Sun Sep 23 22:38:03 2012 [38144] 0 - Sent message to 3 clients

Sun Sep 23 22:38:04 2012 [38144] 0 - Sent message to 3 clients

Sun Sep 23 22:38:04 2012 [38144] 0 - Lost connection, removing it
Sun Sep 23 22:38:04 2012 [38144] 0 - Sent message to 2 clients

Sun Sep 23 22:38:04 2012 [38144] 0 - Sent message to 2 clients

Sun Sep 23 22:38:06 2012 [38144] 0 - Sent message to 2 clients

Från telldus_client_debug:

Code: Select all

Sun Sep 23 22:38:03 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:03 2012 [8464] 333 - Callbackevent, locked
Sun Sep 23 22:38:03 2012 [8464] 3 - Callbackevent, sending
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, locked
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, locked
Sun Sep 23 22:38:04 2012 [8464] 3 - Callbackevent, sending
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:04 2012 [8464] 333 - Callbackevent, locked
Sun Sep 23 22:38:04 2012 [8464] 3 - Callbackevent, sending
Sun Sep 23 22:38:06 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:06 2012 [8464] 333 - Callbackevent, locked
Sun Sep 23 22:38:06 2012 [8464] 333 - Callbackevent, signalled
Sun Sep 23 22:38:06 2012 [8464] 333 - Callbackevent, locked

[krambriw]

Lite fortsatta experiment:

Jag har nu implementerat övervakningen så att den även förväntar sig en ChangeEvent callback efter att jag satt namnet på mitt test device. Nu är ju frågan vilket sätt som är korrekt att återansluta klienten på till Teldus Service...

Jag började med följande när callbacken uteblev (simulerade detta) men det fungerade inte:
- avregistrerar samtliga callback's
- nollställer handles
- stängde biblioteket TelldusCore med tdClose()
- liten paus på några sekunder
- initierade biblioteket med tdInit()
- registrerar nya callback's

Just nu vilket gör att events kommer in:
- avregistrerar samtliga callback's
- nollställer handles
- liten paus på några sekunder
- registrerar nya callback's

Men jag tro inte det räcker om det blir fel. Jag misstänker att man måste använda metoderna tdClose() och tdInit() för att göra ett korrekt avslut innan man ansluter klienten igen.

När jag testar det upprepade gånger (i python) kan jag bara återansluta en gång, sedan smäller det

Code: Select all

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

Som det verkar nu måste jag starta om hela EG men det, lika lite som det kan vara ok att starta om SK's tjänster, är ju inte acceptabelt.

mvh Walter

[latis]

Lösningen som någon hade med Evenghost som känner av en HeartBeat device funkar heller inte för mig, den känner aldrig av att det är fel.

Lite oklart definierat vad det är du använder för program förutom SK. Av ovanstående antar jag att du även kör EG, eller? I så fall betyder det att EG uppenbarligen är nöjd, dvs EG har inga problem med kontakten till Telldus Service. Om EG detekterar problem, så återstartas Telldus Service om du använder den plugin jag la upp ovan i tidigare post. Däremot upptäcker den inte om SK tappat kontakten.

1) Kör du EG också?
2) När det är fel, ser du händelser komma in i EG men inte i SK?

Jag noterade själv idag för första gången detta att händelser inte visades i SK men det fungerade i EG. Lösningen var att starta om SK's tjänster. Jag rörde aldrig Telldus Service.

mvh

1) Ja
2) Ja

Har en lösning om någon kan mer python än jag

Finns en rest plugin till eventghost (http://code.google.com/p/eventghost-switchking-plugin/) som kan ställa en enhet av/på. Skapar man då en dummy enhet (nexa av på) så kommer switchking försöka tända/släcka enheten. När Switchking gör det (förutsatt att anslutning fortfarande finns) kommer en rad dyka upp i eventghost om man har tellstick pluginnet.

Man borde således kunna skicka rest-anropet, vänta på raden, utföra action om raden inte dyker upp (starta om SK tjänsterna, som hjälper mig i dessa fall nu när jag plockat bort en USB förlängning som verkade spöka ibland). Borde vara ett enkelt script, men jag har 0 erfarenhet av python. Kan man via bef. plugins typ var 5:e minut skicka restanropet via rest pluginet och sedan vänta i 10 sekunder på raden (Tex TellStickDuo.Verandan.ON 'selflearning-switch:nexa.64'), kommer den inte inom 10 sek så kör man action att starta om switchkingtjänsterna för att på så sätt tvinga en ny uppkoppling mot telldus service.

[Martin]

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.