Hallo zusammen,
in den letzten Tagen habe ich erfolgreich meinen Telegrambot in Betrieb genommen. Alles lief gut.
Bis heute Morgen. Ich hatte heute Morgen noch 3 Befehle abgesetzt, die auch alle beantwortet wurden. 1 Minute später wollte ich noch einen Befehl absetzen. Doch seit dem bekomme ich vom Bot keine Antwort mehr. Auch vom Bot direkt kann ich keine Nachricht aufs Handy schicken.
Als PollingError erhalte ich folgende Meldung:
Callback returned no valid JSON: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "\r\n
Ich hatte da schon nach gesucht, aber nicht allzu schlüssiges gefunden. Oder ist deren Server überlastet ?
Hat da noch jemand Erfahrung mit gemacht ?
VG und besten Dank
André
VObn serverüberlastung kann ich bei mir nichts erkennen. Wenn das Problem nicht gelöst ist, stelle bitte verbose auf 5, mache bitte ein List von Deinem Device und führe dann einen "set <bot> reset" aus. Dazu würde mich dann der Ausschnitt aus dem FHEM-Log interessieren, dann kann ich vielleicht mehr sagen.
Hi,
habe das mal alles gemacht.
Hier schon einmal das List vom Device:
Internals:
FAILS 0
NAME FHEM32584Bot
NR 357
OLDFAILS 267
OLD_POLLING 13
POLLING 0
SNAME FHEM32584Bot
STATE Polling
TYPE TelegramBot
UPDATER 0
WAIT 0
me Failed - see log file for details
sentLastResult Callback returned no valid JSON: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<html>\r\n<head><tit...") at ./FHEM/50_TelegramBot.pm line 1986.
sentMsgId
sentMsgPeer Andre_XXXXXXXX
sentMsgPeerId 3XXXXXXXXXX
sentMsgText Test
Contacts:
3XXXXXXXXX 3XXXXXXXXX:Andre_XXXXXXX:@StarXXXXXXXXX
Hu_do_params:
NAME
addr https://api.telegram.org:443
boundary TelegramBot_boundary-x0123
buf
code 400
data
displayurl <hidden>
header agent: TelegramBot/1.0
User-Agent: TelegramBot/1.0
Accept: application/json
Accept-Charset: utf-8
Content-Type: multipart/form-data; boundary=TelegramBot_boundary-x0123
hideurl 1
host api.telegram.org
httpheader HTTP/1.1 400 Bad Request
Server: nginx/1.10.0
Date: Fri, 28 Apr 2017 16:03:45 GMT
Content-Type: text/html
Content-Length: 173
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
loglevel 4
method POST
path /bot1e1mj42o6: 1c20";7D k=c$itFM9-lcS"A&<c/sendMessage
protocol https
redirects 0
timeout 30
url https://api.telegram.org/bot1e1mj42o6: 1c20";7D k=c$itFM9-lcS"A&<c/sendMessage
args:
@StarXXXXXXXXXX
Test
undef
0
undef
1
Hash:
Sslargs:
Hu_upd_params:
NAME
addr https://api.telegram.org:443
buf
code 400
conn
displayurl <hidden>
header agent: TelegramBot/1.0
User-Agent: TelegramBot/1.0
Accept: application/json
Accept-Charset: utf-8
hideurl 1
host api.telegram.org
httpheader HTTP/1.1 400 Bad Request
Server: nginx/1.10.0
Date: Fri, 28 Apr 2017 16:06:10 GMT
Content-Type: text/html
Content-Length: 173
Connection: close
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Length,Content-Type,Date,Server,Connection
hu_blocking 0
hu_filecount 1
hu_portSfx
isPolling update
loglevel 4
method GET
offset 0
path /bot1e1mj42o6: 1c20";7D k=c$itFM9-lcS"A&<c/getUpdates?offset=0&limit=5&timeout=60
protocol https
redirects 0
timeout 125
url https://api.telegram.org/bot1e1mj42o6: 1c20";7D k=c$itFM9-lcS"A&<c/getUpdates?offset=0&limit=5&timeout=60
Hash:
Sslargs:
Readings:
2017-04-26 08:36:18 Contacts 3XXXXXXXX:Andre_XXXXXX:@StarXXXXXXXX
2017-04-28 18:06:10 PollingErrCount 358
2017-04-28 18:06:10 PollingLastError Callback returned no valid JSON: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<html>\r\n<head><tit...") at ./FHEM/50_TelegramBot.pm line 1986.
2017-04-26 19:51:23 StoredCommands FHEM set Badheizer on
FHEM set Badsteckdose on
FHEM set Badsteckdose_Taster on
FHEM Barometer
FHEM Telegram
FHEM Verbrauch
FHEM set Badsteckdose_Taster off
2017-04-28 07:08:36 msgChat Andre_XXXXXX
2017-04-28 07:08:36 msgChatId 3XXXXXXXXX
2017-04-28 07:08:36 msgFileId
2017-04-28 07:08:36 msgId 474
2017-04-28 07:08:36 msgPeer Andre_XXXXXXX
2017-04-28 07:08:36 msgPeerId 3XXXXXXXX
2017-04-28 07:08:36 msgReplyMsgId
2017-04-28 07:08:36 msgText Wetter
2017-04-28 07:08:36 prevMsgChat Andre_XXXXXXX
2017-04-28 07:08:36 prevMsgFileId
2017-04-28 07:08:36 prevMsgId 471
2017-04-28 07:08:36 prevMsgPeer Andre_XXXXXXX
2017-04-28 07:08:36 prevMsgPeerId 3XXXXXXXX
2017-04-28 07:08:36 prevMsgReplyMsgId
2017-04-28 07:08:36 prevMsgText Astro
2017-04-28 18:03:45 sentMsgId
2017-04-28 18:03:45 sentMsgPeerId 3XXXXXXXX
2017-04-28 18:03:45 sentMsgResult Callback returned no valid JSON: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<html>\r\n<head><tit...") at ./FHEM/50_TelegramBot.pm line 1986.
Attributes:
allowUnknownContacts 0
cmdKeyword FHEM
cmdRestrictedPeer 3XXXXX
defaultPeer @StargXXXXX
pollingTimeout 60
room FHEMBot
verbose 5
Ich habe gerade versucht, das Log aufzurufen. Doch wird das in Monaten angelegt und ist derzeit schon recht voll.
Irgendwie kommt er bis zum 18.4. und dann lädt er nicht mehr nach.
VG
André
Kannst Du noch etwas versenden? --> also einfach ein
set FHEM32584Bot msg test
Hi,
nein, das geht leider auch nicht. Als MsgResult schreibt er: WAITING und unten drunter steht dann der Text, den ich eingegeben hatte.
Das ist ja das komische. Das sind ja eigenlich "Basics" vom Modul.
Viele Grüße
André
Kannst Du mal versuchen über den BotFather einen neuen API token für Deinen Bot zu erzeugen und dann mit set ... token ... in dem Device einzusetzen?
Ich wüsste zwar nicht wie der kaputt gehen konnte, abereinen Versuch ist es wert
HA ! das wars... viegener !
Ich danke dir recht Herzlich !
Hätte ich nicht gedacht. Wieder etwas gelernt !
Manchmal ist es echt komisch. Ich behalte das mal im Auge... .
Viele Grüße und einen schönen Abend wünscht,
André
Ja, bitte im Auge behalten, dass habe ich nur aus dem list geschlossen. ie das token in fhem kaputtgehen kann ist mir völlig unklar. Wenn das nochmal passiert bitte melden.
Das ist es, in der Tat.
Wie gesagt. Von ein auf die andere Minute, kann man sagen. Heute morgen um 7.08 Uhr alles gut. Um 7.09 Uhr war alles hin.
Und nichts am Modul oder FHEM oder Bot gemacht.
Ich behalte das im Auge. Sollte da noch was kommen, poste ich es hier wieder.
Besten Dank nochmal...
VG
André
Hallo Stargazer & viegener,
genau das gleiche Phänomen hatte ich im Abstand von ca. 3 Wochen ebenfalls schon beobachtet. Das letzte mal heute. Ich kann auch keine äußere Ursache dafür erkennen. Da ich momentan im Urlaub bin und deswegen auch nichts im FHEM ändere, update, anpasse usw. können auch Änderungen in der FHEM-Umgebung dafür nicht in Frage kommen.
Es hat einfach heute morgen nicht mehr funktioniert so wie Stargazer schrieb und nachdem ich meinen API-Key wieder angegeben hatte klappt es nun wieder wie gewohnt.
EDIT: Die Meldung war eine etwa andere und man sieht auch den Timestamp ab wann:
2017.05.01 05:45:00.132 3: TelegramBot_Callback teleBot: resulted in NonBlockingGet: returned <hidden>: malformed or unsupported URL from SendIt
Grüße
Heiko
Da das Token nur geändert wird, wenn explizit gesetzt, kann ich mir nur zwei Dinge vorstellen
Entweder wird aus irgendeinem Grund dder Token überschrieben oder die Decodierung geht aus ungeklärten Gründen schief.
Interessant wäre es herauszufinden, was in diesem Fall in der Datei uniqueID in FHEM/FhemUtils steht.
ABER ACHTUNG: Diese Datei hier nicht posten, denn sie enthält Kennworte!!!
In uniqueID müsste eine Zeile stehen die ungefähr so aussieht:
TelegramBot_einbot_token:012536741d42614044704b623b05550e0a05560204704b62b4905b705424906
Wobei statt einbot dann der Name des Bots steht und dahinter ein Text nur aus Ziffern beziehungsweise Buchstaben a-f steht
Könnt Ihr überprüfen, wenn alles gut geht, was in uniqueid steht und dann im Fehlerfall nochmals überprüfen?
Hallo viegener,
habe gerade festgestellt dass es heute wieder soweit ist und seit ca. 5 Uhr:
TelegramBot_readToken: Error: No API token in file
erscheint.
Bin gerade unterwegs und schaue heute Abend nach dem unique File.
Habe bis jetzt auch keine Idee wie das Problem plötzlich auftreten kann.
Grüße
Heiko
Hallo viegener,
also das Token TelegramBot_teleBot_token war nicht mehr in der Datei.
Ich kann mir aber nicht vorstellen, das es an telegramBot liegt. Habe zwar nicht in den Code geschaut, aber vermute du schreibst den Token beim Setup einmalig dort rein und wird dann nur noch gelesen, oder ?
Heute Nacht 0:25 war die Datei noch ok., 06:25 war dann der Tokeneintrag raus. Das sehe ich anhand von Filesicherungen die regelmäßig auf der NAS laufen.
Eine Idee habe ich aber nach wie vor nicht wie das passieren kann.
Grüße
Heiko
Ich kann mir momentan auch nicht vorstellen, wie das Modul bei Dir den Eintrag in der uniqueid löschen könnte.
Der einzige Punkt, bei dem ein Token gelöscht wird ist bei der Umbenennung des device, aber das wird ja nicht nächtlich und schon gar nicht mit identischem Namen passieren, oder?
Allerdings kann ein anderes Modul oder ein problematischer Aufruf von setKeyValue diesen Eintrag entfernen.
Gibt es andere Einträge in der Datei, die nicht verschwinden?
Nutzt Du selber setKeyValue?
Ja, in SMAEM und SSCam. Allerdings habe ich die auch auf anderen Instanzen laufen (Entwicklung und Test) und habe dort dieses Verhalten noch nie festgestellt. SSCam liest allerdings nur einmal beim Start, würde ich ausschließen.
SMAEM schreibt auch. Allerdings ist zum Beispiel die FHEMId auch noch in der Datei vorhanden. Interessant wäre noch die Info von Stargazer wie es bei ihm aussieht ... er hat ja das gleiche Problem gehabt.
Werde das Mal durchdenken, ergibt für mich noch kein richtiges Bild.
Grüße
Heiko
Laufen irgendwelche besonderen Operationen in der Zeit in dieser Nacht?
Gibt es irgendwelche rename operationen ?
ZitatLaufen irgendwelche besonderen Operationen in der Zeit in dieser Nacht?
nichts besonderes. FileBackups auf der Synology. Dort liegen alle FHEM Verzeichnisse gemountet auf die VM's der ESXi.
ZitatGibt es irgendwelche rename operationen ?
Das kann ich ausschließen
Aber jetzt fällt mir etwas ein ... ich hatte die vergangene Nacht den regelmäßigen Integritätscheck auf dem Synology Filesystem laufen. Das wäre ein Unterschied zum sonstigen Normalbetrieb.
Da ich gerade nicht so gut auf Synology zu sprechen bin, würde ich sofort dem Verdacht folgen...
Im Ernst, was macht der Integritätscheck und wie könnte das einen Einfluss haben?
Läuft FHEM bei Dir auf der Synology?
ZitatDa ich gerade nicht so gut auf Synology zu sprechen bin, würde ich sofort dem Verdacht folgen...
Oh,weshalb das denn ? ...
Zitatwas macht der Integritätscheck und wie könnte das einen Einfluss haben?
Naja, lt. Hilfe wird nach Dateninkonsistenzen gesucht und bereinigt falls etwas gefunden wird.
Ein Zusammenhang wäre wahrscheinlich weit hergeholt (es läuft ja noch mehr parallel ohne Probs). Ich hatte versucht unterschiede zum sonstigen Betrieb zu finden. Es läuft ja normalerweise wochenlang ohne irgendwelche Sorgen.
ZitatLäuft FHEM bei Dir auf der Synology?
Nein, es sind VM's auf ESXi. Aber die Filesysteme der Instanzen (/opt/fhem) liegen auf Syno und sind gemountet. Ist praktisch bzgl. Sicherung usw.
Ich hatte über Wochen Schwierigkeiten mit dem Synology-Support - da sich eine Installation verklemmt hat und die einzige Hilfe, die sie angeboten haben war remote auf mein NAS zu schauen - Befehle für die Lösung oder ein Skript oder was auch immer war nicht möglich.
Am Ende musste ich es quasi neu aufsetzen...
Zum eigentlichen Problem: Ich finde keine Erklärung oder einen Zusammenhang zwischen dem Integritätstest und dem Verschwinden eines Tokens aus der Datei.
Mal so ein paar Ideen:
- Hast Du Devicenamen mit :?
- Gibt es Ähnlichkeiten zwischen verschiedenen Devicenamen/Tokens in der uniqueID (zur Sicherheit: keine Inhalte aus der Datei hier posten)
- Was sagen die Zeitstempel - Änderungsdaten?
Eigentlich habe ich das Gefühl es könnte mit SMAEM zusammenhängen (auch wenn ich dafür nur Indizien habe):
- SMAEM nutzt die Datei zur Zwischenspeicherung von Werten, das ist zumindestens ungewöhnlich
- SMAEM schreibt die Datei in einem BlockingCall (also in einem separaten call) --> Das kann zumindest theoretisch Chaos geben
Sind die SMAEM-Einträge die letzten in der fehlerhaften Datei? Werden diese Summenwerte nachts geschrieben? Gibt es irgendwelche Auffälligkeiten (z.B. log-eitnräge) zu SMA in der Nacht?
Hallo Johannes,
ZitatAm Ende musste ich es quasi neu aufsetzen...
Hmm ... man muß Glück haben an den Richtigen zu kommen. Mit dem Support direkt aus Taiwan, in neuerer Zeit auch aus D, habe ich aber gute Erfahrungen gemacht.
Also inzwischen vermute ich auch das SMAEM-Modul. Es sind zwar keinerlei Auffälligkeiten zu beobachten und ich schreibe auch alle 60 Sekunden in die Datei, nicht nur Nachts. Es muss also eine besondere Situation eintreten. da dieser Fehler nur alle paar Wochen auftritt.
Es ist ja auch so dass setKeyValue zunächst alle Zeilen aus der Datei liest und ggf. verändert wieder reinschreibt. Das würde ja bedeuten setKeyValue würde mal ein paar Zeilen ignorieren weil es meint das Ende der
foreach my $l (@old) { -Schleife erreicht zu haben.
Wie dem auch sei, ich habe heute Vormittag SMAEM so umgeschrieben, dass ich ein eigenes CacheFile benutze und nicht mehr uniqueID dafür nutze.
Ich werde das jetzt testen (kann natürlich wieder ein paar Wochen dauern) und das neue Release auch noch im SMAEM-Thread https://forum.fhem.de/index.php/topic,51569.msg636808.html#msg636808 einstellen.
Falls sich Stargazer nochmal meldet oder dir ein andere User ähnliches berichtet, kannst du ihn auch auf diese Thread verweisen sofern er SMAEM einsetzen sollte.
schönen Feiertag,
Heiko
Hallo Heiko,
soviel Aufwand wollte ich jetzt nicht verursachen, es war wie gesagt nur eine Vermutung.
Trotzdem noch eine Frage: Warum verwendest Du in SMAEM eine separate Datei / uniqueIdi und speicherst die Daten nicht in Readings (auch diese können ja normalerweise gespeichert werden und überleben einen Neustart)?
Hallo Johannes,
Zitat
soviel Aufwand wollte ich jetzt nicht verursachen, es war wie gesagt nur eine Vermutung.
soviel war das nicht ;) Und wenn es damit erledigt sein sollte war es ja auch ein Erfolg.
ZitatWarum verwendest Du in SMAEM eine separate Datei...
Die Readings überleben einen Neustart, das stimmt. Aber nur wenn sie auch im stateFile stehen. Wenn FHEM aber nach einer längeren Laufzeit mal bei einem Nutzer abstürzen sollte, kann es durchaus passieren, dass im statefile nicht der letzte gemessene Zählerstand ist. Dann gibt es mehr oder weniger große Differenzen. Ich habe hier im Forum auch schon gelesen dass die User gern mal das statefile löschen wenn sie auf Fehlersuche sind.
Diese Differenzmessung wird auch deshalb verwendet, um einen Stromausfall (die Zähler im SMA Meter werden dann zurückgesetzt) tolerieren zu können. Es sind also alles Fehlerpräventionen.
VG
Heiko
Zitat von: DS_Starter am 25 Mai 2017, 14:24:08
Die Readings überleben einen Neustart, das stimmt. Aber nur wenn sie auch im stateFile stehen. Wenn FHEM aber nach einer längeren Laufzeit mal bei einem Nutzer abstürzen sollte, kann es durchaus passieren, dass im statefile nicht der letzte gemessene Zählerstand ist. Dann gibt es mehr oder weniger große Differenzen. Ich habe hier im Forum auch schon gelesen dass die User gern mal das statefile löschen wenn sie auf Fehlersuche sind.
OK, verstanden. Ich habe für den Fall die Möglichkeit eingebaut automatisch ein "save" anzustossen, wenn sich die Readings verändern (Über Attribut gesteuert). Ich sehe immer das Problem bei separaten Dateien, dass bei einem Restore / Wiederaufsetzen solche Dateien gerne übersehen / vergessen werden.
Generell würde mich aber vor allem interessieren ob das Problem damit gelöst wäre, aber ich weiss das kann einige Zeit dauern bis wir das glauben können.
ZitatIch sehe immer das Problem bei separaten Dateien, dass bei einem Restore / Wiederaufsetzen solche Dateien gerne übersehen / vergessen werden.
Wahrscheinlich ist es unmöglich jeden erdenklichen Fall abzufangen, aber wir versuchen halt ehrgeizig das Beste zu erreichen. :)
Ja, dann warten wir es mal ab was da raus kommt. Gut wäre auch wenn sich stargazer melden würde und evtl. bestätigen dass er auch SMAEM einsetzt.
Wenn nicht, würde ich fast an ein generelles Problem glauben ... reines Bachgefühl. Denn in den Routinen setkeyValue bzw. FileWrite gibt es ja auch diverse Checks um das File sauber zu öffnen/schreiben.
Bis später mal ...
Heiko
@viegener: Da du schon drin bist ist es eigentlich egal, aber: Ist das noch eine Anfängerfrage?
@KernSani - Inzwischen wohl nicht mehr - aber es wäre schon interessant zu sehen ob es andere gibt, die auch das problem haben (vielleicht gibt es ja doch einen Fehler in meinem Modul und er tritt einfach nur selten auf) - Leider kann man den Fall aber auch noch nicht als gelöst zu den Akten legen
Hallo zusammen,
ich hatte wieder das Problem.
Vor ca. 10 Tagen. Wieder den token eingespielt und seitdem wieder gut.
Das was derzeit Heiko's und mein System gleich nutzen ist das SMAEM.
Es liegt ja sehr nahe, dass es daran liegt. Bei mir laufen die FHEM Instanzen ebenfalls auf VM's (Workstation Pro).
Bin ja echt mal gespannt, was dein umgeschriebenes Exemplar in der Zeit so macht.
VG
André
Na das ist doch mal ein deutliches Indiz - also würde ich jetzt auch erstmal darauf warten ob die Änderung an SMAEM das Problem löst
Zitat von: viegener am 25 Mai 2017, 22:42:13
@KernSani - Inzwischen wohl nicht mehr - aber es wäre schon interessant zu sehen ob es andere gibt, die auch das problem haben (vielleicht gibt es ja doch einen Fehler in meinem Modul und er tritt einfach nur selten auf) - Leider kann man den Fall aber auch noch nicht als gelöst zu den Akten legen
Ich will's ja auch nicht auf gelöst setzen... Aber vielleicht kann der TE ins richtige Forum (Unterstützende Dienste) schieben?
Hallo zusammen,
ja ich denke auch dass wir mit Änderung in SMAEM die Lösung geschaffen haben.
@Andre, kannst du bitte, sofern noch nicht geschehen, die geänderte SMAEM-Version hier https://forum.fhem.de/index.php/topic,51569.msg640013.html#msg640013 runterladen und bei dir einbauen !? (Restart nicht vergessen)
In ein bis zwei Wochen vlt. auch drei, wissen wir dann ganz genau ob es die Lösung war und können uns zu dem Ergebnis wieder abstimmen.
Grüße
Heiko
Zitat von: viegener am 01 Mai 2017, 22:23:52
Da das Token nur geändert wird, wenn explizit gesetzt, kann ich mir nur zwei Dinge vorstellen
In uniqueID müsste eine Zeile stehen die ungefähr so aussieht:
TelegramBot_einbot_token:012536741d42614044704b623b05550e0a05560204704b62b4905b705424906
Ich habe auch das Problem, dass seit einigen Tagen (ohne wissentliche Änderung meinerseits) Fehlermeldungen auftauchen
2020.01.03 11:35:00 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:37:19 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:39:39 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:42:01 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:44:23 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:46:50 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:49:14 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:51:39 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:54:05 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:56:32 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 11:59:01 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:01:30 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:04:00 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:06:31 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:09:03 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:11:36 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:14:07 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:14:07 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:14:11 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:16:46 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:19:22 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:20:03 1: TelegramBot_readToken: Error: No API token in file
2020.01.03 12:20:10 1: ./www/images/fhemSVG/fussgaenger.svg is not useable
2020.01.03 12:20:44 1: ./www/images/openautomation/phone_call_end_out.svg is not useable
2020.01.03 12:20:44 1: ./www/images/openautomation/phone_missed_out.svg is not useableDie entsprechende Datei enthält aber
Zitat
TelegramBot_TelegramBot_token:***********************************************************
Das letzte Mal half ein Neustart von FHEM. Aber wieso taucht das Problem auf?
@andies: In diesem Thread war die letzte Vermutung, dass ein anderes Modul möglicherweise den Eintrag gelöscht hat. Ist aber ein sehr alter Thread (von 2017 und hat möglicherweise mit Deinem Problem nichts zu tun).
Hast Du SMAEM im Einsatz? Sonst ist das vermutlich nicht der richtige Thread. Wenn Du sonst insbesondere im Bot geändert hast, würde ich immer noch vermuten, dass es ein anderes Modul oder ein anderer Effekt (Name eines Devices mit ":") dafür gesorgt hat.
Die Lösung um das Problem erstmal zu lösen ist aber auch hier im Thread beschrieben - hat aber nichts mit Neustart zu tun.
Nein, das habe ich nicht. Mich wundert auch, dass irgendwelche svg nicht mehr nutzbar sind - das hat ja mit dem Bot nichts zu tun, sondern FTUI. Vermutlich ist das am Ende ein Netzwerkproblem?
Hallo,
ich glaube, das eigendliche Problem ist inzwischen durch
Zitat von: andies am 03 Januar 2020, 16:24:02.
Nein, das habe ich nicht. Mich wundert auch, dass irgendwelche svg nicht mehr nutzbar sind - das hat ja mit dem Bot nichts zu tun, sondern FTUI. Vermutlich ist das am Ende ein Netzwerkproblem?
Netzwerkproblem - wieso sind die Dateien übers Netz angebunden? - Ansonsten deutet da für mich noch nichts daraufhin
Wenn es sich um einen Raspi mit SD-Karte handelt deutet ein solches Problem mit mehreren Dateien auch Richtung SD-Karten-Lebensende?
Heisst Dein TelegramBot wirklich TelegramBot, sonst ist die Zeile in uniqueid komisch.
Zitat von: Peteruser am 03 Januar 2020, 21:50:46
Hallo,
ich glaube, das eigendliche Problem ist inzwischen durch
Den Kommentar verstehe ich nicht - hattest Du auch ein Problem?