Hallo Zusammen,

ich benutze in einer Hausautomation für die komplette Lichtsteuerung und Rollladensteuerung die SONOFF DualR3 im Schaltschrankt. Davon sind ca. 25 .. 30 Stück verbaut. Alle sind mit Tasmota 10.x geflasht und unterschiedlich programmiert - weil Shutter oder Taster. Immer wieder fällt mir einer der SONOFFs aus und geht einfach aus und reagiert auf nichts mehr, auch nicht auf den Button am Gerät. Meist (zu 99%) hilft dann den SONOFF stromlos zu machen und wieder anzuschliessen, dann startet er wieder und funktioniert auch wieder. Es ist natürlich NICHT immer der Gleiche und ein paar habe ich inzwischen auch schon ausgewechselt. Ich kann nicht sagen ob es eine gibt der das besonders oft macht oder nicht - vom Gefühl ist es immer ein anderer. Um dem Problem auf die Spur zu kommen habe ich mir die Werte in den Objekten angesehen. Dabei ist mir aufgefallen, dass es SONOFFs gibt die mit 30°C CPU Temperatur arbeiten und andere mit bis zu 70°C. Meine Vermutung war nun, das es ein Thermikproblem ist und daher logge ich mal alle CPU Temperaturen der SONOFFs mit. Dabei wiederum zeigt sich, dass die, egal welche Temperatur sie haben, immer eine gleichmäßige Kurve haben. Also der mit 65°C läuft, läuft immer mit um die 60°C. Ich komme nicht so regelmäßig an den Schaltschrank ran daher weiß ich nicht, ob die Dinger wirklich so warm werden. Ich vermute aber nicht. Ich warte jetzt auf den nächsten Ausfall um dann nachsehen zu können mit welcher Temperatur der SONOFF lief ...
Kann man die CPU Temperatur in TASMOTA kalibrieren? (Habe schon nachgeschaut, aber in der Tasmota Doku nichts passendes gefunden)
Kann es sein das der SONOFF abschaltet wenn er meint die Temperatur ist zu hoch?
Hat jemand ein ähnliches Problem und das evtl. sogar gelöst?

Bei mir geht der OctoPrint Adapter nach kurzer Zeit und immer öfter wieder auf Gelb.

Im LOG steht

octoprint.0	2021-03-14 20:16:16.862	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:16:07.495	info	(24486) OctoPrint API not connected
octoprint.0	2021-03-14 20:15:16.739	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:14:16.615	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:13:16.491	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:12:16.354	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:11:16.232	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:11:07.495	info	(24486) OctoPrint API not connected
octoprint.0	2021-03-14 20:10:16.109	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:09:15.990	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:08:15.864	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:07:15.724	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:06:15.578	info	(24486) timeout of 2000ms exceeded
octoprint.0	2021-03-14 20:06:07.495	info	(24486) OctoPrint API not connected
octoprint.0	2021-03-14 20:06:01.435	info	(24486) timeout of 2000ms exceeded

Hin und wieder ist der Adapter auch längere Zeit grün. Kann ich denn Einfluss auf den timeout nehmen? Es ist ein lokales Netz ..
Die Version 1.5.4 von OctoPrint ist im Einsatz, der oben beschriebene Fehler ist es also nicht ..

@freundernacht
Ich kämpfe derzeit ebenfalls mit den HM Heizkörperthermostaten und habe festegestellt, dass der CONTROL_MODE nur eine Info ist (0=Auto, 1=Manu, 2= Party und 3=Boost) Geschaltet wird über die "BUTTON" Datenpunkte AUTO_MODE, BOOST_MODE (boolean) und MANU_MODE (Temperatur) und PARTY-MODE (nach Eingabe der Anfangs- und Endzeit über die jeweiligen DPs) und ggf. über LOWERING_MODE bzw. COMFORT_MODE

Hat sich erledigt. Per Skript funktioniert es dann doch, wenn alle Syntaxfehler raus sind

@paul53 Sorry - mein Fehler! Ich war beim falschen Taster. (ich war beim Shelly i3) :-[
Ich nehme alles zurück und behaupte das Gegenteil.

Hallo zusammen,

ich möchte in der VIS per HTML eine Tabelle anzeigen. Dafür verwende ich Datenpunkte aus dem ioBroker. Diese kann ich in HTML ja so darstellen {ble.0.irgendwas.datenpunkt} Wenn jetzt allerdings irgendwas eine MAC Adresse ist - wie der BLE Adapter die anlegt dann scheint die HTML Umsetzung zu streiken. Auch per Skript scheint es sich an dem Datenpunkt mit der MAC Adresse zu stören.
Wie kann ich ds lösen?

@RalfR72
Hallo, ich werte das anders aus. Ich triggere den Counter und hole mir dan den Event zur Auswertung. Der Status ist nur auf tru solange der Taster betätigt wird.

@simatec ok. ich schreib den Satz noch mal vollständig und richtig
DropBox-Zugriff kann es m.E. nicht sein, da das CCU Backup und der Rest der iobroker Sicherung ordentlich in die DropBox geschrieben wird

@simatec Das hat leider nicht geholfen

Was mir aber im LOG aufgefallen ist, dass BackItUP versucht aus dem Verzeichnis [iobroker/historyDB] Daten zu sichern. Standardmäßig liegen die Daten doch aber in iobroker/iobroker-data und an den Standardeinstellungen hatte ich erst nichts geändert. Aber selbst wenn ich beim History Adapter angebe dass er nach historyDB schreiben soll macht er das nach iobrocker-data/historyDB wenn ich keinen absoluten Pfad angebe. Aber auch wenn ich in backitUp den historyDB/ oder den iobroker-data/historyDB Pfad eintrage kommt im LoG immer die gleiche Meldung:
backitup.0 2020-05-15 01:04:50.012 debug (331) [iobroker/historyDB] [IGNORED] No source for compress!
ich habe auch schon den history Adapter deinstalliert und neu installiert - leider ohne Erfolg.

Hallo Zusammen

Ich habe das gleiche Problem. ioBroker auf proxmox, backitup in Dropbox.
Hat lange funktioniert neuerdings steht im Debug.log die Meldung:
2020-05-11 02:00:12.722 - debug: backitup.0 (11599) [iobroker/iobroker] host.Hoehlenbroker 10107 states saved
2020-05-11 02:00:12.793 - debug: backitup.0 (11599) [iobroker/iobroker] host.Hoehlenbroker 10756 objects saved
2020-05-11 02:00:17.210 - debug: backitup.0 (11599) [iobroker/iobroker] Backup created: /opt/iobroker/backups/iobroker_2020_05_11-02_00_10_ioB-WH_backupiobroker.tar.gz
2020-05-11 02:00:18.244 - debug: backitup.0 (11599) [iobroker/iobroker] done
2020-05-11 02:00:18.245 - debug: backitup.0 (11599) [iobroker/historyDB] [IGNORED] No source for compress!
2020-05-11 02:00:18.246 - debug: backitup.0 (11599) [iobroker/dropbox] Copy iobroker_2020_05_11-02_00_10_ioB-WH_backupiobroker.tar.gz...
2020-05-11 02:00:53.008 - debug: backitup.0 (11599) [iobroker/dropbox] File "/opt/iobroker/backups/historyDB_2020_05_11-02_00_18_backupiobroker.tar.gz" not found
2020-05-11 02:00:53.008 - debug: backitup.0 (11599) [iobroker/dropbox] done
2020-05-11 02:00:53.009 - debug: backitup.0 (11599) [iobroker/clean] Backup files not deleted from /opt/iobroker/backups because some errors.
2020-05-11 02:00:53.009 - debug: backitup.0 (11599) [iobroker/clean] done

History-sicherung ausgeschaltet, History neu gestartet und Pfad aus History im BackItUp adapter eingetragen (ist der Gleiche, wie wenn man die Datenübernahem aus Histroy macht) Trotztdem passiert immer wieder der der gleiche Fehler. DB Zugriff kann es nicht sein, da CCU Backup und der Rest vom ioBrocker in die DP geschrieben wird. Nach was muss ich denn suchen? Welche Source ist denn nicht da? Mein History adapter funktioniert sauber, also müssen ja Daten da sein ...