@MCU
Betrifft StateListHistory, laut Web-Doku

Bitte im Jarvis Import-Script stateListeItemHistory.js folgende Anpassung vornehmen (oder zumindest entsprechenden Hinweis in der Web-Doku.
(Mit meiner Erweiterung sollte es für beide Typen funktionieren)

window.Socket.subscribeState(darkModeDPsl, ({ err, state }) => {
	themeDarkModeItem = state.val;
	// Datenpunkttyp wurde in 3.2.0-betaX von boolean in string geändert
	if (typeof(state.val) == 'string') {
		if (state.val == 'on') {
			themeDarkModeItem = true;
		}
		else {
			themeDarkModeItem = false;
		}
	}
	resetCurves();
});

Betrifft Jarvis 3.2.0-beta.39 und ff, da sich der DP-Typ von "jarvis.0.settings.themeDarkMode" von boolean auf string geändert hat.

Siehe auch:

@mcu
So, nun ausgiebig getestet und funktioniert super

Könntest du bitte noch im stateListeItemHistory.js beim PopUp die ToolTip Konfig noch anpassen?
Das Datum ist hier in JJJJ-MM-TT und die Uhrzeit in UTC weshalb diese um 2Std. abweicht, weil hier nur die Substrings vom TS ausgegeben werden.
Hier die neue Zeile:

html += '           formatter: function(params) { var formattedTS = (new Date(params[0].value[0])).toLocaleString("de-DE"); let d = String(params[0].data); let sp = d.split(","); return sp[1] + " ' + historyItemValuesObj[isTempDP].unit + ' am \\n" + formattedTS}';

Ansosten: Hatte ich das schon erwähnt? Ich find dieses Zusatz-Feature so geil

iob diag, stimmt. Hatte das mit iob fix verwechselt.

Ich hab ne NVME als boot und root.
Wenn iobroker nach network.target schon startet, ist das Netzwerk noch nicht online!
D.h. es funktionieren noch keine Zugriffe nach außen, was zu Fehler im ioBroker Log führt.
Seitdem ich das auf 'network-online.target' geändert habe, startet ioBroker etwas später und die Meldung ist weg.

Sorry, 7.4.10 (hatte ich 7.4.0 geschrieben?)
Na wenn deins auch so ausschaut, sind wir schon 3

Wie kommst du zu dieser Beurteilung, dass dies völlig irrelevant ist?
Das kann ich leider nicht so ganz nachvollziehen.

IOB DIAG könnte ich schon machen, aber dann zerschießt es mir die angepasst Service Konfiguration vom ioBroker.
Und die musste ich anpassen, da der ioBroker zu früh und zu schnell gestartet wird, obwohl das Netzwerk noch nicht komplett oben ist. Was wiederrum Fehler im ioBroker Log provoziert.

Das ist kein Problem. Was wollt ihr für die Fehlerbeseitigung haben?

Bedeutet das letztlich, dass es für jeden besser gewesen wäre auf eine kostenpflichte Lösung zu setzen, wenn man ein nahezu fehlerfreiese und funktionierendes System haben will?
Dir ist aber schon klar, dass die Entwickler kostenpflichtiger SW, teilweise genauso selten auf gemeldete Fehler reagieren und oft nur wenn sich genügend Anwender beschwert haben. Geld ist also mitnichten ein Garant.
Und ist 'das' jetzt das allgemein gültige Totschlag Argument? 'Ist doch kostenlos, sei doch froh wenn es überhaupt startet'
???

Ich merke schon, dass führt hier in keinsterweise zur Fehlerbeseitigung, sondern nur zu verschwendeter Zeit...

Persönlich finde ich deartiges Verhalten echt schade. und beende das jetzt für mich.
Zurückbleibt auf jeden Fall ein gefrusteter Anwender. Aber das schein ja beabsichtigt zu sein, oder mindestens tolleriert.

Ach ja, falls einer von Euch ein Auto fährt...
Ihr habt der Werkstatt eures Vertrauen mitgeteilt, dass im Bordcomputer immer mal wieder eine Fehlermeldung "xyz..." auftaucht.
Wie würdet ihr das jetzt finden, wenn der Werkstattmeister zu Euch sagt: Sie können auch gerne eine Ausbildung zum Mechatroniker machen und den Fehler selber beheben... hmmpf

Das war jetzt ein Scherz "Wieso, das gibt es doch IMMER!" oder? Denn das sollte schon vermieden werden.
Spasshalber deswegen, weil ich von vorherein wusste, dass es an keinem anderen Adapter liegt

Die Fehlermeldung tritt seit dem Admin-Adapter Update, definitiv beim Starten des ioBroker auf!
Ein bisschen Jornal interpretieren kann ich dann doch schon 🤨
Das hat also nichts direkt mit dem Betriebsystem zu tun. Wird ioBroker nicht gestartet, erscheint der Fehler nicht.

Verstehe jetzt echt nicht, warum man nicht einfach mal kurz schaut, was vor der 7.4.0 und der letzten Final Release, geändert wurde.

Und ja, ich habe im System das eine oder andere unerwünschte Verhalten in anderen Adaptern.
Wie soll ich jetzt beurteilen, dass es nicht genau an diesem Fehler liegt?
Wie wollt ihr beurteilen, dass dieser Fehler nicht irgendwann, (was weiß ich, bei der Nutzung der RTC oder, I2C, oder SPI Schnittstelle, oder beim Restore mit dem Backitup-Adapter) zu einem unerwünschten Verhalten führt???
Wenn sich da im nachhinein heraustellt, dass hier z.B. ein unerwünschter Benutzerwechsel statt fand, und deshalb sämtliche Sicherungen unbrauchbar sind, was dann?

Ist das jetzt auch sinnvoll, hier darüber zu diskutieren, anstatt die wertvolle Zeit lieber dafür zu nutzen, mal nachzuschauen Das ist doch völlig unökonomisch

Nun stell ich die Frage mal einfach andersrum:
Wieso führt der Admin ein SU unter pi/root aus und was bezweckt der damit?
Denn das ist nun mal leider Fakt.

Und ja, ich weiß, dass hier ist alles kostenlos und ihr macht das hier alles in Eurer Freizeit.
Das finde ich auch wirklich toll, absolut lobenswert und verdient meinen höchsten Respekt.
Nur ist das jetzt kein Grud hier so derart, sorry, gelinde gesagt rumzuzicken.
Wenn ihr keine Lust habt der Sache nachzugehen, dann sagt dass doch bitte einfach klipp und klar.
Da bin ich zwar auch nicht begeistert, kann das aber eher akzeptieren, als das herumgefrage, am Fehler vorbei.

Und jetzt dürft ihr mich für die klaren Worte steinigen...

@erwin-lindemann said in pam_unix(su:auth): authentication failure:

"MESSAGE" : "FAILED SU (to pi) iobroker on none",

Also ganz erhrlich, Failed, auf deutsch Fehler: Da gibt es eigentlich nichts miszuinterpretieren.
Das sind keine "normalen" Meldungen, sorry.
Ein Fehler der keiner ist, sollte auch nicht als solcher ausgewiesen werden!
Die Meldung kommt aber vom Betriebsystem, und aus dessen Sicht ist es eben ein Fehler.
Die Meldung kommt auch erst mit der 7.4.0 also wurde dort definitiv was verändert und falsch gemacht.

Stell dir vor, auf deinem Bordcomputer im Auto erscheint eine Fehlermeldung.
"Es ist ein Fehler xyzgjklhjkhkj265415 aufgetreten"
Wie willst du als Fahrer beurteilen, dass das jetzt kein Fehler ist, und nur ausgegeben wurde weil der Computer lustig ist?

Sorry, aber diese Diskussion über Fehlermelden, die keine sind, führt nirgendwo hin.

Übrigens, ich bin seit ca. 30 Jahren als Anwendungsprogrammierer tätig
Ich glaube also schon beurteilen zu können, welche Meldungen erwünscht oder unerwünscht sind, und welchen Meldungen man einfach nachgehen muss.
Alleine schon die Anzahl der Buchstaben, die ich hier tippe, rechtfertigen eine Korrektur

Hi, nicht das ich oder du, das missverstehen.
Die Einträge sind direkt nach dem Boot zu sehen (ca. 20 - 30s).
Bevor ich überhaupt was gemacht habe.
Und ich habe noch spasshalber, mal vor dem reboot alle Adapter (außer SQL) deaktiviert.

Nachtrag:
Das hier ist der Journal Eintrag im JSON-Format. Vielleicht hilft das weiter...

"SYSLOG_IDENTIFIER" : "su",
        "_TRANSPORT" : "syslog",
        "_GID" : "1001",
        "_SYSTEMD_UNIT" : "iobroker.service",
        "_SOURCE_REALTIME_TIMESTAMP" : "1736458064847155",
        "_COMM" : "su",
        "_SYSTEMD_CGROUP" : "/system.slice/iobroker.service",
        "_UID" : "1001",
        "__REALTIME_TIMESTAMP" : "1736458064847173",
        "_RUNTIME_SCOPE" : "system",
        "_PID" : "1127",
        "_MACHINE_ID" : "99533e3d94294e8cb275bda4b4efdb3f",
        "_SYSTEMD_SLICE" : "system.slice",
        "SYSLOG_FACILITY" : "4",
        "_CMDLINE" : "su pi",
        "SYSLOG_TIMESTAMP" : "Jan  9 22:27:44 ",
        "__MONOTONIC_TIMESTAMP" : "28596057",
        "SYSLOG_PID" : "1127",
        "PRIORITY" : "5",
        "_CAP_EFFECTIVE" : "1ffffffffff",
        "_HOSTNAME" : "RaspberryPi5-Ede",
        "MESSAGE" : "FAILED SU (to pi) iobroker on none",
        "__CURSOR" : "s=e679325809684b9ea0bb1c9a44d12a16;i=fcdd0;b=5943f75f76ad426d99c023bcf6a255fc;m=1b45759;t=62b4ca61f6145;x=62add599ef783ca",
        "_BOOT_ID" : "5943f75f76ad426d99c023bcf6a255fc",
        "_EXE" : "/usr/bin/su",
        "_SYSTEMD_INVOCATION_ID" : "8e53fe42df9945bdb6c1cf27328cabcc"

Hallo zusammen.

Habe heute auch erstmalig obige Fehlermeldung im Journal gefunden:
'journalctl -p 6 -b'
Das Journal habe ich z.Z. äußerst intensiv unter Beobachtung, da ich dort gerade versuche anderweitige Fehler (Blutooth, NVME usw. wegzubekommen.
Außedem gerada am Testen welche Sicherungsmethode inkl. Restore, fehlerfrei funktioniert. (Z.Z immer nur offline mit ausgebauter NVME) So viel zur Vorgeschichte.
Daher ist mir eben sofort dieser Fehler aufgefallen und bin mir auch sicher, das der 'Fehler' durch den letzten Admin-Adapter Update auf 7.4.0 reinkam.
Das hier ist meine Konfiguration:

Und das hier aus 'systemctl --no-pager status iobroker.service'

pi@RaspberryPi5-Ede:/home $ systemctl --no-pager status iobroker.service
● iobroker.service - ioBroker Server
     Loaded: loaded (/lib/systemd/system/iobroker.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-01-09 23:18:36 CET; 8min ago
       Docs: http://iobroker.net
   Main PID: 3798 (iobroker.js-con)
      Tasks: 206 (limit: 9566)
        CPU: 2min 34.898s
     CGroup: /system.slice/iobroker.service
             ├─3798 iobroker.js-controller
             ├─3816 io.admin.0
             ├─3863 io.email.0
             ├─3896 io.roborock.0
             ├─3917 io.backitup.0
             ├─3943 io.zigbee.0
             ├─3963 io.sql.0
             ├─3983 io.mqtt.0
             ├─4004 io.lgtv.0
             ├─4021 io.tr-064.0
             ├─4038 io.snmp.0
             ├─4054 io.tankerkoenig.0
             ├─4071 /opt/iobroker/node_modules/go2rtc-static/dist/go2rtc -config "{\"streams\":{\"73bFdmT97kAlNsmA7Xa5s…
             ├─4079 io.javascript.0
             ├─4107 io.web.0
             ├─4175 io.jarvis.0
             ├─4194 io.echarts.0
             ├─4337 io.reolink.0
             └─4416 io.kisshome-research.0

Jan 09 23:19:03 RaspberryPi5-Ede sudo[3999]: iobroker : PWD=/opt/iobroker/node_modules/iobroker.backitup ; USER=…backups
Jan 09 23:19:03 RaspberryPi5-Ede sudo[3999]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Jan 09 23:19:03 RaspberryPi5-Ede sudo[3999]: pam_unix(sudo:session): session closed for user root
Jan 09 23:19:36 RaspberryPi5-Ede bash[3798]: ================================== > LOG REDIRECT system.adapter.ja…ogging]
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5658]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt -v
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5658]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5658]: pam_unix(sudo:session): session closed for user root
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5663]: iobroker : PWD=/ ; USER=root ; COMMAND=/usr/bin/apt list --upgradeable
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5663]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=1001)
Jan 09 23:20:51 RaspberryPi5-Ede sudo[5663]: pam_unix(sudo:session): session closed for user root
Hint: Some lines were ellipsized, use -l to show in full.

Jedenfalls bin ich erst Mal beruhigt, dass es nicht an mir liegt und andere den gleichen Fehler haben.

Liebe Grüße und, ihr leistet echt ne tolle Arbeit!
Was würde ich nur anstellen ohne Raspi + ioBroker + Jarvis?
(Am Auto schrauben bei dieser Eiseskälte, macht nicht wirklich Spaß

Cool, sag ich nur...