NEWS
js-controller 3.2 jetzt im Latest!
-
@feuersturm Für seq das hier in iobroker.json einfügen...
https://github.com/ioBroker/ioBroker.js-controller/blob/master/conf/iobroker-dist.json#L114-L121und natürlich richtige werte setzen. Dann "enable" auf true und iobroker neu starten
-
@apollon77 Danke für die Info zur Konfiguration von Seq. Was wird denn mit dieser Aktivierung zusätzlich geloggt was der Seq Adapter nicht empfangen kann?
-
@feuersturm Am Ende ist es der Controller Start und alles andere Vor dem seq-Adapter-Start ... bzw nachdem er beendet wurde
-
@apollon77 passt hier ggf nicht ganz hin, aber ich hab nen Syslog-Server auf meiner DS918+ laufen. Proxmox sendet da schon fein hin - in der json aber sind so viele Einstellungen, die ich nicht bewerten kann...
Hab folgendes in der json hinterlegt - aber auf meiner Syno kommt nix an? path_comment weiß ich schon nicht was das ist? Bei Proxmox musste ich mehr oder weniger nur IP, und Port für den Server angeben, wohin gesendet wird...Hab auf IETF und Post 520 gewechselt, mal schauen ob was ankommt. Den Port 514 nutze ich für Proxmox
"type": "syslog", "enabled": true, "host": "192.168.178.31", "host_comment": "The host running syslogd, defaults to localhost.", "port": "520", "port_comment": "The port on the host that syslog is running on, defaults to syslogd's default port(514/UDP).", "pid": "0", "protocol": "udp4", "protocol_comment": "The network protocol to log over (e.g. tcp4, udp4, unix, unix-connect, etc).", "path": "", "path_comment": "The path to the syslog dgram socket (i.e. /dev/log or /var/run/syslog for OS X).", "facility_comment": "Syslog facility to use (Default: local0).", "localhost": "iobroker", "localhost_comment": "Host to indicate that log messages are coming from (Default: localhost).", "sysLogType_comment": "The type of the syslog protocol to use (Default: BSD).", "app_name_comment": "The name of the application (Default: process.title).", "eol_comment": "The end of line character to be added to the end of the message (Default: Message without modifications)."
-
@apollon77 Ich kann bestätigen, dass nach dem einfügen des Codeschnipsels in der iobroker.json für seq die Log Infos direkt in Seq landen
-
@kueppert adde mal ein "port" noch mit dem echten Wert. DIe "*_comment" beschreibeen die Felder - daher ist da ein text drin ... alles was ein _comment hat kannauch als "" hinterlegt werden
-
@apollon77 hab IETF in die json manuell hinzugefügt gehabt mit
"sysLogType": "IETF"
...danach ließ sich der Broker nicht mehr starten...hab die Zeile wieder entfernt.
Hab meine Konfig gerade etwas umgebaut und diesen Winston Syslog unter /opt/iobroker nachinstalliert...ich schaue jetzt mal. WIll hier nicht so oft spamen und was nachträglich ändern ^^ -
@kueppert also ich hab nicht mehr gesetzt als Du oben ... aber hab auch nen "klassischen udp syslog" und mach es nicht per synology ...
-
@apollon77 hast du denn diesen
npm install winston-syslog
installiert unter /opt/iobroker? Ich glaube ich mach morgen weiter...2 EInträge hab ich im Protokoll-Server gefunden, die sind aber schon was her... ich glaub ich versuche morgen weiter, bevor ich mein Prod-System schrotte -
@kueppert winston-syslog ist eine der optionalen deps die an sich mit installiert werden ... In dem Zuge kommen auch immer diese "unix_dgram" Fehler die man so kennt ... schau mal ob in node_modules bzw node_modules/iobroker.js-controller/node_modules ein winston-syslog Verzeichnis existiert. ggf dort mal "npm i" machen
-
@apollon77 ok...ich habs eben schon installiert hab ich hier in einem anderen Beitrag aus 2019 gelesen...schlimm?
hab jetzt auch was im Syslog auf der Syno bekommen sieht nicht schön aus, aber ist was da (ist ein HTML-Export, damit man was lesen kann)
dieser hier: https://forum.iobroker.net/topic/3863/iobroker-logging-zu-syslog/22
-
@kueppert sagte in js-controller 3.2 jetzt im Latest!:
@apollon77 ok...ich habs eben schon installiert hab ich hier in einem anderen Beitrag aus 2019 gelesen...schlimm?
alles gut
-
@apollon77 Ich habe die 3.2.16 installiert und bekomme jetzt im Log im Millisekunden Abstand folgende Meldungen.
2021-02-12 23:58:57.994 - info: hm-rpc.0 (COMPACT) setState not processed because States database not connected 2021-02-12 23:58:57.994 - info: hm-rpc.0 (COMPACT) setState not processed because States database not connected 2021-02-12 23:58:57.994 - info: hm-rpc.0 (COMPACT) setState not processed because States database not connected 2021-02-12 23:58:57.996 - info: hm-rpc.0 (COMPACT) setState not processed because States database not connected 2021-02-12 23:59:06.957 - info: hm-rpc.0 (COMPACT) setState not processed because States database not connected
Diese Infos lassen sich auch nicht abstellen, in dem ich bei der hm-rpc.0 Instanz das Loggen auf "warn" oder höher stellen.
-
@marty56 dann bitte sicherstellen das du die aktuellste hm-rpc hast und am besten einmal die ganze Compact Gruppe bzw. den Controller neu starten.
Dann am besten nach restart mal hm-Rpc stoppen und neu starten und dann schauen ob es wieder passiert. Wenn ja GitHub issue beim Adapter anlegen.
-
@apollon77
Ich habe die allerneuste Version.
Was letztlich geholfen hat, war iobroker restart.
Das Verhalten trat auf, als ich meinen Linux Server neu gestartet hatte.Ich vermute, dass das Timing beim Laden der Adapter dann etwas anders ist, und der hm-rpc sich merkt, dass vielleicht die redis Datenbank noch nicht gestartet war.
-
@marty56 um da aus den Annahmen rauszukommen schau doch mal im logfile wann es genau angefangen hat.
-
Kurze Rückmeldung von mir:
Bin jetzt seit 3 Tagen auch auf 3.2.16 - bisher alles gut, mein Lets Encrypt funktioniert auch endlich wieder
Good Job
-
Hallo zusammen, ich war jetzt ein paar Tage Stabil auf der 3.2.16 und wollte heute meinen geplanten Umzug vom LXC Container in eine VM durchführen (spart mir einen Raspi da ich die Smartmeter per USB in der VM dann durchreiche).
Restore wie gewohnt per iobroker restore 0 (schon x-mal gemacht).
Allerdings bekomme ich beim Starten jedes einzelnen Adapters diese Warnungen (der Port auf localhost wechselt allerdings):
2021-02-13 14:18:07.542 - warn: host.pve-vm-iobroker Objects 127.0.0.1:38656 Error from InMemDB: Error: client NOT SUPPORTED 2021-02-13 14:18:07.600 - warn: host.pve-vm-iobroker Objects 127.0.0.1:38658 Error from InMemDB: Error: client NOT SUPPORTED 2021-02-13 14:18:07.600 - warn: host.pve-vm-iobroker Objects 127.0.0.1:38660 Error from InMemDB: Error: client NOT SUPPORTED
Das System läuft auf objects:file / states:redis und der Redis-Server läuft aktuell noch in dem ursprünglichen Container (die Warnungen gibt es aber auch wenn ich ihn lokal in der VM installiere).
ioBroker Config:
Multihost discovery server: disabled Discovery authentication: enabled Objects: file on 0.0.0.0 States: redis on 10.4.1.5
Redis läuft auf 10.4.1.5 -> Port 6379
nmap -p- 10.4.1.5 Starting Nmap 7.70 ( https://nmap.org ) at 2021-02-13 14:26 CET Nmap scan report for 10.4.1.5 Host is up (0.00012s latency). Not shown: 65528 closed ports PORT STATE SERVICE 22/tcp open ssh 111/tcp open rpcbind 139/tcp open netbios-ssn 445/tcp open microsoft-ds 6379/tcp open redis 37043/tcp open unknown 43699/tcp open unknown
Hat jemand eine Idee wo ich ansetzen muss?
-
@darkiop ja, dein "Objects master" (host.pve-vm-iobroker) läuft nicht auf 3.2.x Master updaten bitte
-
@apollon77 Ok, Fehler 40 mal wieder ... Danke dir!!