Daten über den Neustart hinaus erhalten

Begonnen von Dynalon, 30 Dezember 2020, 17:57:16

Vorheriges Thema - Nächstes Thema

Dynalon

Hallo zusammen,

ich bin mir sicher, so etwas gibt es schon. Nur komme ich leider entweder nicht auf den richtigen Suchbegriff oder suche an der falschen Stelle.

Aber vielleicht erst mal von vorne:
Mein FHEM-Raspberry 3B ist alle paar Wochen in die Knie gegangen und hat plötzlich Anfragen nicht mehr bearbeitet oder ähnliches. Auch der Seitenaufbau im Browser wurde immer langsamer. Ich habe dann heraus gefunden, dass er einfach viel zu viele temporäre Daten mit sich rumschleppt. Kurzum: Seit er sich jede Nacht um 4 Uhr per Cronjob selbst neu startet (Stichwort Cache leeren)  läuft er nun seit Monaten perfekt.

Nun zu meiner Frage:
Nach dem Neustart bekommt er alle Werte wie Wind, Temperatur usw. automatisch über kurz oder lang von den anderen Geräten zugeschickt. Und ob jetzt eine Lampe an oder aus ist, klärt sich spätestens beim nächsten Schalten (zumal ein Doif jede Nacht um 3 alle vergessenen Lichter ohnehin ausschaltet).
Aber manche Daten will ich über den Reboot sichern (z.B. wer ist zu Hause - er soll ja auch wenn wir zu Haus sind morgens um 5 das Licht an machen, wenn einer am Bewegungsmelder vorbei geht und anders herum im Urlaub passend auf Einbrecher reagieren, ohne dass ich den Status jeden morgen neu eingeben muss. Andere Beispiele sind: Läuft der 3D Drucker noch? Ist die Waschmaschine fertig? Ist es ok, dass das Schlafzimmerfenster offen ist, weil wir ja zu Hause sind? ...).
Wie erstelle ich eine (beispielsweise Text-)Datei, in der solche wichtigen Zustände über den Reboot hinaus gespeichert werden?

Wie gesagt, die passende Lösung gibt es bestimmt schon, nur finde ich sie leider nicht.

Freue mich über den passenden Link!!!

Vielen Dank und viele Grüße,

Dynalon

Beta-User

Normalerweise speichert FHEM die Zustände aller Readings, wenn es sauber runtergefahren wird (statefile).

Ergo ist dein System zu beschäftigt, um das ordentlich abzuschließen, wenn da Lücken auftreten. Von daher lohnt es sich m.E., die Ursachen für das "Zumüllen" zu suchen und die zu bekämpfen, statt die Symptome zu kurieren... Ein FHEM-Server sollte Monate laufen können, ohne dass man ihn neu starten müßte.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Dynalon

Hallo Beta-User,

vielen Dank für Deine Antwort. Ich bin jetzt nicht sicher, wie viele Monate ein FHEM Server laufen soll, bis er zugemüllt ist. Habe aber gesehen, dass bei mir auch recht viel Verkehr ist. Mehr als 8-12 Wochen oder 2-3 Monate lief er geschätzt schon, bevor Probleme auftraten, vielleicht auch länger. Ich weiß nur, dass ich irgendwann beim 3. oder 4. "nicht reagieren auf einen Schaltbefehl" (System ist seit etwas über 3 Jahren in Betrieb) angefangen habe zu googeln und seitdem den Cronjob drin habe.

Was hauptsächlich so an "Müll" in meinem FHEM herumgeistert, sind massenweise solche Dinge wie hier (kleiner Auszug aus dem Logfile):
2020.12.30 19:25:56 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2020.12.30 19:25:56 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out


Solchen Datenmüll erhalte ich für zig Geräte (ausgeschaltete Deckenlampen, Gartenbeleuchtung, die im Winter im Keller liegt, Poolsteuerung, die über die kalte Jahreszeit vom Netz genommen wird,...) alle 5 Sekunden. Die Erklärung ist andererseits sehr einfach: Diese Lampen etc. sind halt alle gerade stromlos (weil mit dem Lichtschalter ausgeschaltet oder ausgestöpselt), also an sich gewollt, auch wenn ich die Nachricht jetzt nicht alle 5 Sekunden im Logfile haben will - leider aber auch nicht weiß, wie ich das verhindere.
Habe das daher nie als "zu beseitigen" gesehen, sondern halt einfach damit gelebt.

Bin aber nun anders herum dem Fehler näher gekommen. Du sagtest, FHEM sollte eigentlich alles beim Beenden speichern. Nun hab ich halbwissend wie ich bin folgendes ausgeführt:

sudo su
sudo crontab -e
00 4 * * * sudo reboot


Wahrscheinlich habe ich hier den "Fehler" somit selbst verursacht, denn vermutlich wird FHEM so nicht korrekt beendet. An sich habe ich das aber nicht für ein Problem gehalten, da mir nicht bekannt war, dass FHEM alles beim Beenden speichert.
Ein täglicher Reboot wäre zwar nicht notwendig (alle 2 Monate würde locker auch reichen), habe es einfach so eingerichtet, weil "um 4 Uhr" leichter zu merken ist als "jeden 1. Januar, März, Mai,... um 4 Uhr". Und irgendwie mag ich das Gefühl eines "frischen" Systems am Morgen.

Kann ich meinem Raspi beibringen, dass er vor solch einem Reboot alles ordnungsgemäß speichert? Das Logfile beispielsweise geht vom 1.12. bis heute - dieses wird also gesichert. Ich ging nur davon aus, dass nicht jeder Dummystatus oder jeder Status einer Lampe ebenso gesichert wird (zumindest hab ich im FHEM Wiki keinen Hinweis darauf gefunden oder war auf der Zeile blind). Wenn Du mir nun sagst, dass jedes Schalten innerhalb von Sekunden automatisch gesichert wird für den Fall eines Stromverlusts, habe ich mir Sorgen um ein Problem gemacht, das gar nicht da ist.

Beta-User

Oh je....

Da sind aber viele Baustellen offen.
Beschäftige dich vielleicht als erstes mit attr ... disable, morgen dann zu. mehr.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Dynalon

...das mit den Baustellen gebe ich leider gern zu. Sind bestimmt einige Dinge, die bei meinem FHEM nicht perfekt sind. Habe leider bei absolut null angefangen und bisher weder privat, noch von Ausbildung und Beruf jemals irgendwas mit Elektronik, Programmieren etc. zu tun gehabt. Andersrum bin ich sehr stolz, trotzdem irgendwie meine Tasmota-Dosen geflasht zu bekommen, Yeelight in FHEM einzubinden und den Homematic Rollladen mit nem ZWave Thermometer zu verknüpfen. Aber leider passieren da halt auch Fehler.

Zwar macht es mir Spaß, doch ist es schwer auf "keine Grundkenntnisse" aufzubauen. Ich wünsche mir seit Jahren mal nen persönlichen Kontakt zu jemandem mit etwas Ahnung zu haben (der mir dann auch mal aufzeigt, wo diese Fehler alle liegen), doch bin ich traurigerweise der Erfahrenste den ich kenne. Und wenns gar nicht geht (oder ich beim Googeln nichts finde), frage ich halt hier nach...

Wie auch immer, gehe gern mal das Kapitel durch, vielleicht weiß ich morgen dann mehr.

Otto123

Hi,

auch ein reboot führt normal zum speichern der fhem.save
Du solltest also mal früh kurz nach 4:00 schauen:
ls -lha /opt/fhem/log/fhem.save
Damit wir wissen ob zumindest dies mit rechten Dingen zugeht.

Gruß Otto

P.S in deiner Anleitung sind zwei sudo unnütz ;)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Fyi: ich habe auch mal bei 0 angefangen, und wenn mir vor 7 Jahren einer prophezeit hätte, dass ich mal Microcontroller programmieren würde (also "hardcore" mit MySensors) oder Perl-Kenntnisse aufweisen würde: großes Gelächter...

Also vorab: halte dich möglichst an die Doku die "hier" zu finden ist. Hier = commandref, Wiki, Forum. Alles andere können wir im Fehlerfall nicht verbessern, und du darfst mir glauben: Es steht unglaublich viel veraltetes oder schlicht untaugliches da draußen (abgesehen von der Doku, die jeweils zu externen Projekten gehört; wer z.B. zigbee2mqtt nutzt, sollte auch deren Projektseiten und Wiki lesen.).

Ziel sollte sein, dass FHEM stabil läuft und du diesen "fix" komplett abschaffen kannst. Ich hatte früher auch uptimes eher in Monaten gerechnet, heute ist das schwieriger, weil ich manchmal eben zu Testzwecken ein sehr aktuelles FHEM+meine Testfassungen von Modulen brauche ;) .

Konkreter Aktionsplan:
- Vorgehensweise ändern:
-- Statt reboot (=> cronjob wieder löschen!) System beobachten => "top" auf OS-Ebene (@Otto: dachte erst, wir hätten es mit einem Speicherleck, zu tun, aber wenn das bereits nach einem Tag so schlimm ist, sieht es eher nach blocking calls aus, oder?)
-- Was du längerfristig abschaltest, solltest du deaktivieren. Das disable-Attribut wäre hier uU. für einen Teil eine Lösung, bei Shelly muss man das Intervall ändern usw. usf.. Mußt du sehen, was das jeweilige Modul vorsieht. V.a., wenn das Kontaktieren selbst Zeit kostet (dns-lookup), können sonst ein paar stromlose Devices schon großen Schaden anrichten, weil Timings nicht mehr passen usw.. Da kann man ggf. die IP statt des hostname verwenden, dann fällt der Teil wenigstens weg. etc. pp..

- Wenn der reboot zu verlorenen Daten führt, klingt das nach Zwangsbeendung, denn eigentlich wird auch dann sauber die FHEM-statefile geschrieben; nur eben nicht, wenn FHEM zu langsam reagiert. Tippe auf hängende Prozesse.

- es kann auch was externes sein, das den Server beschäftigt. Wie loggst du? FileLog oder DbLog? Läuft eine GUI (=>weg damit! Für Grafik reservierten Speicher dann freigeben. Dto. für "Schmutz" wie samba.)?

- Perl und OS wären interessant, ebenso die Modulversionen. Es gibt einen ultralangen Thread zu Speicherproblemen, aus dem sich leider kein Rezept mit Erfolgsgarantie ableiten  ablesen läßt, aber tendenziell: möglichst alles updaten, Perl nach 5.28 oder später ziehen.

- Ansonsten solltest du dir die Event-Seite mal ansehen; hier hatten wir jüngst eine schöne Diskussion über vieles, was damit zusammenhängt: https://forum.fhem.de/index.php/topic,117075.0/topicseen.html
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

CBSnake

Moin,

ich setz mich einmal im Monat mit nem großen Pott Kaffee vor den PC, auf dem einen Monitor läuft der Eventmonitor, auf dem zweiten rufe ich das Device auf.
Einfach mal laufen lassen und bei jedem Event prüfen: brauche ich dieses Event wirklich, brauche ich es in dieser Regelmäßigkeit? Ändern kann man es dann gleich am zweiten Bildschirm.
Klar ist ohne event-on-change-reading ist im Eventmonitor die Hölle los ;-) und man kann unmöglich jedes einzelne Event erfassen und prüfen. Einfach mal anfangen.
So lässt sich so aber Recht schnell reduzieren und man kann sich dann bei der nächsten Prüfung mit den neuen Devices befassen die man zwischenzeitlich angelegt hat.
FHEM auf Debian 10, HM-Wlan, JeeLink-Wlan, Wlanduino, ConBee, TP-Link Steckdose, GHoma Steckdosen, Shelly Steckdosen

Wzut

#8
Zitat von: Beta-User am 31 Dezember 2020, 06:56:20
- Wenn der reboot zu verlorenen Daten führt, klingt das nach Zwangsbeendung, denn eigentlich wird auch dann sauber die FHEM-statefile geschrieben;
Bis das endgültig gekärt ist würde ich erst einmal einführen :
define at_fhemsave at *3:50:00 {WriteStatefile}
damit dürfte der Wunsch einigermassen gültige Ist Werte nach Neustart zu haben erfüllt sein.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Wernieman

Was mich noch beschäftigt: ist wirklich ein reboot des PIs nötig? Reicht nicht ein ein restart von fhem?
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Dynalon

Hallo,

schonmal vielen Dank für dieses viele Input. Werde mich nun meine nächsten freien Tage hinsetzen und

1. Ich werde testen, ob vor dem Neustart automatisch gespeichert wird. (Kann sein, dass er es seit jeher macht, ohne dass ich es gemerkt habe, als Windows User, der schon zig Dokumente verloren hat, weil sein Betriebssystem während der Mittagspause spontan Updates installiert und ohne autospeichern neu startet, ist man ja einiges gewohnt).

2. Ich werde versuchen, mein "Logfile aufzuräumen" - es wäre schon eine schöne Sache. Die Lampen-Connect-Timeouts konnte ich vorerst unterbinden, (auch wenn das nur das Protokollieren abschaltet, nicht die Anfrage meines Pi's selbst, oder?). Betonung auf KONNTE, denn gestern waren sie weg, heute wieder da. Naja, morgen gehe ich mal die Event-Seite an.

3. Zu diesen Lampen: Ich benutze die meisten davon täglich, sie werden per Lichtschalter ein und ausgeschaltet. Je nach Laune mache ich sie - wenn sie an sind - warmweiß, kaltweiß oder farbig. Aber solange sie eben aus sind, kann sich mein Raspi damit nicht connecten. Irgendwann werden die Lichtschalter vielleicht abgeschafft, aber im Moment möchte ich es so. Ich bin auch nicht sicher, ob es Sinn macht, die Anfrage vom Raspberry zu ändern. Schließlich sollen die Lampen ja auch funktionieren, wenn ich den Lichtschalter umlege. Kennt jemand da eine besser Lösung? Wenn ja, welche/wie?

4. Was die anderen Geräte angeht, die nur je nach Jahreszeit geschaltet werden (Poolsteuerung, Gardenpoles, Solarthermie,...)
Ich hatte überlegt, diverse Dummies anzulegen, so dass ich das eine oder andere Doif bei Nichtgebrauch "abklemmen kann" (beispielsweise am Tag wo ich den Pool winterfest mache, den Dummy "Poolsteuerung" auf off zu setzen, der wiederum in jedem mit dem Pool verknüpften Doif die erste Bedingung ist. So würden zumindest die Doifs nicht mehr ausgeführt, wenn die Geräte abgeklemmt sind).
Doch dann nach und nach irgendwann 20 oder mehr Dummies zu haben, erschien mir auch nicht sonderlich elegant. So kam ich zu der Überlegung, diverse Werte in einer gesammelten Textdatei zu speichern, die dann einzeln veränderbar und auch nach Neustart, Stromverlust etc. per FHEM abrufbar sind, weswegen ich wiederum diesen Thread gestartet hatte.


Zum Logfile:
Vermutlich (oder eher sehr wahrscheinlich) "müllt" sich mein System mit viel zu vielen Anfragen zu, es sind eigentlich immer die selben paar Zeilen, die sich teilweise im 5-Sekundentakt wiederholen. Eine davon ist diese:

2021.01.01 18:11:37 3 : RaspBee: message for unknown device received: RaspBee-4
2021.01.01 18:11:37 3 : RaspBee: message for unknown device received: RaspBee-6
2021.01.01 18:11:37 3 : RaspBee: message for unknown device received: RaspBee-3
2021.01.01 18:11:37 3 : RaspBee: message for unknown device received: RaspBee-5

- nur leider habe ich in diesem Fall keine Ahnung, von welchem Device sie kommen (irgendwann habe ich die Zeilen im Logfile bemerkt, es fiel aber mit keiner Neuinstallation eines Geräts o.ä. zusammen, was einen Rückschluß auf die Quelle geben könnte. Ich weiß nur so viel: RaspBee ist mein ConBee II Stick, der nun meine ZigBee geräte steuert. Das sind aber nur Lichter und Steckdosen - keine Schalter oder Sensoren, die meinen Raspi anfunken sollten. Einzige Ausnahme: Mein Aqara Cube, der aber dank seiner Bauart (Knopfzelle) nicht solch einen Funkverkehr verursachen kann).

Ein weiteres Beispiel, das neuerdings auftaucht ist von meinem Fibaro Zwave Auge:
2021.01.01 17:49:55 1: PERL WARNING: Argument "5 Lux" isn't numeric in numeric lt (<) at (eval 18508) line 1.
Hier kann ich den Fehler nachvollziehen, es hat irgendwann (ggf. nach einem Update?) angefangen für den Wert Helligkeit statt "5" irgendwann "5 Lux" zu senden. Nun könnte ich mein Doif anpassen:
([ZWave_SENSOR_NOTIFICATION_4:"on"] and [ZWave_SENSOR_NOTIFICATION_4:luminance] < 28) (set Wohn3 on-for-timer 900)
ZWave_SENSOR_NOTIFICATION_4 ist das Gerät, "on" bezeichnet eine Bewegungserkennung und luminance die Helligkeit, die dieses Gerät dabei gemessen hat. Diesen Sommer lief es wie gewollt nur bei Dunkelheit, im Winter wird es ohnehin nie heller als 27 Lux in unserem Wohnzimmer.
Statt "<28" könnte ich für jeden Wert eine Zeile in einem Doelseif schreiben, aber elegant wäre das auch nicht. = 9 Lux, doelseif = 8 Lux, doelseif = 7 Lux ... usw. Nur die Fehlermeldung wäre dann weg. Leider weiß ich anders herum nicht, wie ich den Wert "luminance" von diesem Gerät ohne "Lux" hinter der Zahl darstellen lassen kann.

Leider muss ich gestehen es ist mir peinlich, denn ich weiß, in meinem FHEM existieren viele Anfängerfehler, die ich nicht ausgemerzt habe. Für gewöhnlich versuche ich nach dem FHEM Wiki vorzugehen. Das schönste Beispiel ist das Modul Alarmanlage:
https://wiki.fhem.de/wiki/Modul_Alarm
Ich habe es zwar hinbekommen, dieses zu installieren und einen Alarm scharf zu schalten oder die Scharfschaltung zu widerrufen, doch leider nie, einen Alarm über einen Bewegungsmelder auszulösen.
Leider komme ich in solchen Punkten selbst oft nicht weiter. Andere Quellen, die dann eben das, was man nicht weiß auch nicht als selbstverständlich voraussetzen sind dann manchmal die letzte Lösung. Eine einfache Frage wie die nach Shelly Devices

Ich möchte niemanden dazu nötigen, Stunden zu investieren, mit mir mein ganzes FHEM aufzuräumen, schließlich hat jeder seine eigenen Projekte. Wenn ich es eben nicht besser als holpernd schaffe, dann ist es leider so. Ich hoffe, irgendwann finde ich die eine oder andere Lösung und kann es dann optimieren. Daher frage ich normalerweise auch nur dann, wenn es bei mir gar nicht weitergeht.
Lange Rede, kurzer Sinn: Wenn jemand von Euch bereit ist, mir wirklich auf banalster Ebene zu erklären, wie ich mein System "entmülle", bin demjenigen unglaublich dankbar - aber das sprengt definitiv den Rahmen an gegenseitiger Mithilfe, den man in einem Forum erwarten kann.



Zum protokollieren verwende ich FileLog. Ein GUI läuft soweit ich weiß nicht (außer dem normalen Raspbian. Ich reboote vor jeder großen Änderung, stecke vorher einen Monitor an und fertige über die Raspbian Bordmittel eine Kopie der SD Karte an. Sobald dieses Backup abgeschlossen ist, ziehe ich den HDMI-Port und reboote über Putty erneut. So bleibt zumindest der HDMI Port abgeschaltet. Die Sicherungen führe ich auf diese Art durch, da das die einzige mir bekannte Methode ist, das Image auch auf eine kleinere Speicherkarte zu ziehen. Hatte vorher Probleme, wenn ich von einer 29,0002GB Karte auf eine 29,0001GB Karte wechseln wollte. Da ich weiß, dass ich in meinem FHEM immer wieder Fehler mache, habe ich mehrere rollierende Sicherungskopien, um notfalls zurück gehen zu können, wenn ich etwas für meine Fähigkeiten irreversibel zerschieße).

Ich hoffe, mit Modulversionen ist dies gemeint:

Latest Revision: 23446

File               Rev   Last Change

fhem.pl            23445 2020-12-31 14:39:10Z rudolfkoenig
95_Alarm.pm        17344 2018-09-14 14:05:23Z phenning
96_allowed.pm      23247 2020-11-28 10:44:57Z rudolfkoenig
98_autocreate.pm   23006 2020-10-22 19:40:17Z rudolfkoenig
00_CUL.pm          21659 2020-04-13 10:08:36Z rudolfkoenig
10_CUL_HM.pm       23421 2020-12-26 15:11:46Z martinp876
18_CUL_HOERMANN.pm 15510 2017-11-27 16:52:44Z rudolfkoenig
14_CUL_MAX.pm      22175 2020-06-13 17:32:49Z Wzut
14_CUL_TX.pm       17102 2018-08-08 05:34:42Z rudolfkoenig
14_CUL_WS.pm       20918 2020-01-08 19:20:38Z rudolfkoenig
98_DOIF.pm         23418 2020-12-26 10:04:12Z Damian
98_dummy.pm        20665 2019-12-06 11:05:35Z rudolfkoenig
34_ESPEasy.pm      18608 2019-02-16 09:03:52Z dev0
91_eventTypes.pm   14888 2017-08-13 12:07:12Z rudolfkoenig
01_FHEMWEB.pm      23405 2020-12-22 21:31:51Z rudolfkoenig
92_FileLog.pm      23138 2020-11-11 20:43:14Z rudolfkoenig
30_HUEBridge.pm    23363 2020-12-16 09:35:18Z justme1968
31_HUEDevice.pm    23344 2020-12-13 17:05:33Z justme1968
10_IT.pm           20839 2019-12-28 09:41:47Z bjoernh
10_MAX.pm          23290 2020-12-04 11:49:41Z Wzut
10_MQTT2_DEVICE.pm 23382 2020-12-19 11:40:59Z rudolfkoenig
00_MQTT2_SERVER.pm 23326 2020-12-11 17:47:10Z rudolfkoenig
91_notify.pm       21427 2020-03-15 10:10:32Z rudolfkoenig
70_Pushbullet.pm    9730 2015-10-30 15:06:41Z fhainz
99_SUNRISE_EL.pm   22789 2020-09-18 19:00:46Z rudolfkoenig
98_SVG.pm          23373 2020-12-17 18:53:33Z rudolfkoenig
98_telnet.pm       23434 2020-12-29 20:22:05Z rudolfkoenig
98_update.pm       20778 2019-12-18 17:46:44Z rudolfkoenig
99_Utils.pm        22524 2020-08-02 14:34:02Z rudolfkoenig
98_version.pm      15140 2017-09-26 09:20:09Z markusbloch
98_weblink.pm      16293 2018-02-28 21:33:57Z rudolfkoenig
98_XmlList.pm      22518 2020-08-02 10:25:25Z rudolfkoenig
# $Id: 32_YeeLight.pm 2017-07-30 thaliondrambor $
10_ZWave.pm        23384 2020-12-19 17:34:05Z rudolfkoenig
00_ZWDongle.pm     23140 2020-11-11 21:22:55Z rudolfkoenig

AttrTemplate.pm    22985 2020-10-18 09:04:19Z rudolfkoenig
Blocking.pm        23268 2020-12-01 11:48:48Z rudolfkoenig
Color.pm           20813 2019-12-22 18:42:10Z justme1968
DevIo.pm           23241 2020-11-27 16:25:33Z rudolfkoenig
GPUtils.pm         19666 2019-06-20 11:17:29Z CoolTux
HMConfig.pm        23420 2020-12-26 15:03:01Z martinp876
HttpUtils.pm       22917 2020-10-05 14:37:58Z rudolfkoenig
Meta.pm            21008 2020-01-18 10:22:10Z loredo
RTypes.pm          10476 2016-01-12 21:03:33Z borisneubert
SetExtensions.pm   23300 2020-12-06 11:36:24Z rudolfkoenig
TcpServerUtils.pm  22894 2020-10-01 19:49:32Z rudolfkoenig
ZWLib.pm           17186 2018-08-20 20:10:55Z rudolfkoenig

doif.js                    15546 2017-12-03 09:57:42Z Ellert
fhemweb.js                 23409 2020-12-23 11:08:10Z rudolfkoenig


Otto123

#11
Hi,

ich nehme mal die einfache Geschichte aus deinem langen Text :)
ändere den Ausdruck so ab:
[ZWave_SENSOR_NOTIFICATION_4:luminance:d]
Dann hast Du die Perl Warnung nicht mehr.
Zur Erklärung: Schau in der Doku nach "Filtern nach Ausdrücken mit Ausgabeformatierung"

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Rom wurde nicht an einem Tag erbaut, und es sind vermutlich eine Vielzahl an Schritten, die du gehen musst. Otto hatte ja schon mal mit einer "keinen Kleinigkeit" angefangen ;) .

So kannst du dann eben nach jeder "Kleinigkeit" suchen, aber es sind ja gar nicht so viele Module involviert, und alles scheint halbwegs aktuell zu sein :) .

Für die RaspBee-Dinger habe ich auch erst mal keine Erklärung, aber es klingt so, als würden Daten empfangen. Also würde ich autocreate einschalten und dann mal schauen, was da so kommt. Sind es nicht "deine" Devices, ist das zwar komisch, aber im Egebnis macht das ja nichts; einfach dann z.B. mit einem "ignore" versehen und irgenwo hinpacken, wo es nicht stört ;) .

Bei den Timeout-Dingern würde mich interessieren, was es für ein Modul ist. Irgendwo stand was von wegen Yeelight, aber ein entsprechendes Modul ist gar nicht geladen. Also MQTT2_DEVICE?

Was das mit dem HDMI-Kabel angeht, klingt das schon nach GUI, also einer grafischen Oberfläche. Empfohlen ist hier tendenziell, nur die "lite"-Version zu installieren (ohne GUI). Ist denn wenigstens das OS aktuell ) "lsb_release -a" auf der Linux-Kommandozeile zeigt das, "ps -e | grep X" könnte anzeigen, ob ein X läuft ...
Für backups würde ich mir was anderes überlegen, im Zweifel Karte raus und irgendwo ein Linux bereithalten, um ggf. dann auch kleinere Images zu ziehen oä. (Würde tendenziell eher immer den Installationsweg wählen und schauen, dass (nur) die Nutzdaten gesichert sind; ist aber auch eine Geschmacksfrage).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wernieman

Für ein Dump der SD-Card könnte man auch ein Windows nehmen. Das blöde ist nur, das so ein Dump manuell erzeugt werden muß. Wer ein manuelles Backup noch nie vergessen hat, hebe bitte die Hand ...

Deshalb: Kannst Du ein automatisches Backup der fhem Config machen? Aber auf anderes Speichermedium als die Interne SD ..
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Dynalon

Hallo zusammen,

ich wollte mal kurz Feedback geben, woran ich bin.

Erst noch einmal vielen Dank! Einiges hat schon ganz gut geklappt.

1.
Habe es mal getestet: Nach einem Neustart werden sämtliche Einstellungen von FHEM übernommen. (Da ist das Programm tatsächlich um einiges schlauer als mein Windows 10! Microsoft, schneide Dir bitte ne Scheibe von ab, Du schaffst das seit Jahrzehnten nicht!)

2.
Die Raspbee Geräte habe ich tatsächlich identifizieren können, aus meinem FHEM gelöscht und neu angelernt. Damit sind diese Fehlermeldungen verschwunden.

3.
Vielen Dank an Otto für den Tipp zum Filtern nach Ausgabeformatierung. Hat einwandfrei geklappt und läuft seitdem fehlerfrei. Denke, ich werde noch ein paar andere Zeilen auf diese Art anpassen können.

4.
Etwas merkwürdiger ist es mit dem Ausblenden meiner beiden Yeelight Lampen aus dem globalen Logfile. Während die Lampe aus der Küche nicht mehr im Logfile auftaucht, klappt das Ausblenden der Esszimmerlampe nicht - die taucht weiterhin im global Logfile weiterhin alle paar Sekunden auf. Dann plötzlich kommt auch die Küchentischlampe wieder, dafür die Esszimmerlampe nicht. Bevor ich versucht hatte, beide mit
attr global ignoreRegexp .*AbCd.*|.*CdEf.*: auszublenden, kamen sie immer gleichmäßig, alle paar Sekunden die eine und eine Sekunde später die andere. Jetzt kommt die eine 10x und ich denke, zumindest die andere ist weg, schwupp kommt die zweite dafür mehrfach, während dann die erst weg ist. Habe zwischendrin nochmal versucht, sie ausblenden zu lassen - kann es sein, dass der Befehl, eine Lampe auszublenden, die andere automatisch wieder einblendet? Das macht doch keinen Sinn! Ich kapier das nicht!

2021.01.04 18:51:35 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:52:40 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:53:44 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:54:01 3: CUL433 IT_set: Wohn3 on
2021.01.04 18:54:47 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:55:52 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:56:55 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:58:02 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 18:59:03 3: CUL433 IT_set: Wohn3 on
2021.01.04 18:59:06 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:00:11 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:01:14 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:02:18 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:03:21 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:04:07 3: CUL433 IT_set: Wohn3 on
2021.01.04 19:04:26 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:05:32 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:06:36 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:07:41 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:08:45 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:09:52 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:10:56 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:12:02 2: EsszimmerStehlampeY: connect to http://192.168.178.131:55443 timed out
2021.01.04 19:12:27 3: CUL433 IT_set: Wohn3 on
2021.01.04 19:13:06 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:14:10 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:15:14 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:16:17 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:17:22 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:18:26 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:19:32 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:20:29 3: CUL433 IT_set: Wohn3 on
2021.01.04 19:20:36 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:21:42 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out
2021.01.04 19:22:46 2: KuechentischlampeY: connect to http://192.168.178.133:55443 timed out

(Wohn 3 ist der Lichtschalter, der vom Bewegungsmelder angeschaltet bzw. eingeschaltet gehalten wird)

Hier würde ich mich noch über einen Tipp freuen, wieso sich die beiden Lampen aus dem Logfile nicht ausblenden lassen, wenn Ihr einen habt!

Vielen Dank!