@thomas-braun

======================= SUMMARY =======================
		     v.2023-04-16


Operatingsystem: 	Raspbian GNU/Linux 10 (buster)
Kernel: 		5.10.103-v7l+
Installation: 		Native
Timezone: 		Europe/Berlin (CEST, +0200)
User-ID: 		1000
X-Server: 		false
Boot Target: 		graphical.target

Pending OS-Updates: 	0
Pending iob updates: 	0

Nodejs-Installation: 	/usr/bin/nodejs 	v18.16.1
			/usr/bin/node 		v18.16.1
			/usr/bin/npm 		9.5.1
			/usr/bin/npx 		9.5.1

Recommended versions are nodejs 18.x.y and npm 9.x.y
Your nodejs installation is correct

MEMORY: 
              total        used        free      shared  buff/cache   available
Mem:           3.8G        1.7G        1.1G         40M        1.0G        2.0G
Swap:           99M          0B         99M
Total:         3.9G        1.7G        1.2G

Active iob-Instances: 	28
Active repo(s): beta

ioBroker Core: 		js-controller 		5.0.8
			admin 			6.6.0

ioBroker Status: 	iobroker is running on this host.


Objects type: jsonl
States  type: jsonl

Status admin and web instance:
+ system.adapter.admin.0                  : admin                 : iobroker                                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
+ system.adapter.web.0                    : web                   : iobroker                                 -  enabled, port: 8082, bind: 0.0.0.0, run as: admin

Objects: 		9261
States: 		7961

Size of iob-Database:

33M	/opt/iobroker/iobroker-data/objects.jsonl
11M	/opt/iobroker/iobroker-data/objects.json.migrated
11M	/opt/iobroker/iobroker-data/objects.json.bak.migrated
2.4M	/opt/iobroker/iobroker-data/states.jsonl
1.5M	/opt/iobroker/iobroker-data/states.json.migrated
1.5M	/opt/iobroker/iobroker-data/states.json.bak.migrated



=================== END OF SUMMARY ====================

dpkg --print-architecture
armhf

@ticaki

32 Bit

Wir hatten letzte Woche einen Stromausfall d.h. alle Raspis ausgefallen.
Nach dem Wiederanlauf ist mir das Problem das erste mal aufgefallen.

Kann jetzt aber nicht sagen, ob es an dem js-controller Update lag oder am Stromausfall.

Da das Problem wohl mehrere haben, gehe ich von einem Bug aus.

Hi.

habe das selbe Problem auf einem Raspberry Pi4. Scheint Betriebssystem-Unabhänging zu sein.

Meine Konfig:
Raspbian 10
js-controller 5.0.8
admin 6.6.0
hm-rpc 1.15.8

Auf Github hat schon wer ein Issue erstellt:
https://github.com/ioBroker/ioBroker.hm-rpc/issues/954

kago76 created this issue in ioBroker/ioBroker.hm-rpc

open instance crashes sporadically after js-controller update 5.0.8 #954

@eLichte said in Modbus:

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Ich habe im Github einen Fork gezogen und quick&dirty mit meinen bescheidenen Programmierkenntnissen eine sleep-Funktion eingebaut. Wollte nur mal testen ob das tatsächlich was bringt. Das log sieht jetzt so aus:

modbus.0	2019-05-10 10:26:07.043	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-05-10 10:26:06.836	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.835	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-05-10 10:26:06.692	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.692	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-05-10 10:26:06.517	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.516	debug	Poll inputRegs DevID(2) address 3634 - 8 bytes
modbus.0	2019-05-10 10:26:06.324	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.324	debug	Poll inputRegs DevID(2) address 3602 - 18 bytes
modbus.0	2019-05-10 10:26:06.119	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:06.118	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-05-10 10:26:05.844	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.844	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-05-10 10:26:05.700	debug	Wait: 100ms
modbus.0	2019-05-10 10:26:05.700	debug	Poll inputRegs DevID(2) address 0 - 1 bytes
modbus.0	2019-05-10 10:26:05.699	debug	Poll device 2

So läuft die Kommunikation seid ein paar Wochen ohne Fehler. Es ist also tatsächlich so, dass der Server für manche Clients zu schnell ist.

@iomountain said in iobroker installation defekt?:

Wenn es an denn Rechten liegt, schon mal den iobroker-installation-fixer versucht?

Das war die Lösung, dankeschön.

Der Hinweis dazu steht auch hier:
http://www.iobroker.net/docu/?page_id=8323&lang=de

hatte ich zuvor nicht gefunden.

Zusatz:

pi@ioBroker-Pi:~ $ node -v
v8.15.1
pi@ioBroker-Pi:~ $ nodejs -v
v8.15.1
pi@ioBroker-Pi:~ $ npm -v
6.4.1

Hallo,

ich habe den iobroker auf einen raspberry neu aufgesetzt und mit backitup eine Sicherung eingespielt.
Es scheint alles zu funktionieren. Auch die Adapter laufen alle.
Wenn ich allerdings am Terminal ein

sudo iobroker status

eingebe, kommt folgende Fehlermeldung:

module.js:550
    throw err;
    ^

Error: Cannot find module '/home/pi/node_modules/iobroker.js-controller/iobroker                             .js'
    at Function.Module._resolveFilename (module.js:548:15)
    at Function.Module._load (module.js:475:25)
    at Function.Module.runMain (module.js:694:10)
    at startup (bootstrap_node.js:204:16)
    at bootstrap_node.js:625:3

Nach recherchen im Forum vermute ich ein Problem mit der js-controller Installation.
Ich habe folgende Vorgehensweise gefunden und getestet:

sudo systemctl stop iobroker
sudo su
cd /opt/iobroker
sudo chmod 777 * -R
sudo npm install iobroker.js-controller --production

Danach scheint der js-controller wieder zu funktionieren. "iobroker status" bringt keine Fehlermeldung mehr. Wenn ich den PI allerdings neu starte, habe ich die wieder die Probleme von oben.

Kann mir hier jemand helfen? Danke.

Der Verdacht zu Punkt 1 hat sich bestätigt. Der Master schickt zu schnell wieder eine Querry message an den Slave nach dessen Antwort. Wenn ich nur 5 zusammenhängende Register abfrage läuft die Kommunikation ohne Probleme.

modbus.0	2019-02-28 11:32:51.341	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:51.341	debug	Poll device 2
modbus.0	2019-02-28 11:32:41.290	debug	Poll inputRegs DevID(2) address 2006 - 5 bytes
modbus.0	2019-02-28 11:32:41.290	debug	Poll device 2

Auszug aus dem Handbuch einer Daikin Klimaanlage:

(T1-T2-T3-T4) ist wie folgt definiert: 5ms bei 9600bps und 2,5ms bei 19200bps

Ich werde dazu einen Issue im Github erstellen. Evlt kann da jemand eine Verzögerungszeit einbauen. Meine Porgrammierkenntnisse reichen dafür leider nicht.

Hi,
ich habe jetzt auch den Modbus Adapter mit RS485 als Master im Einsatz.
Auch bei mir verabschiedet er sich regelmäßig mit timeout Fehlern.

Wenn er läuft sieht der log so aus:

modbus.0	2019-02-26 09:25:49.868	debug	Poll holdingRegs DevID(2) address 2051 - 12 bytes
modbus.0	2019-02-26 09:25:49.803	debug	Poll holdingRegs DevID(2) address 2003 - 27 bytes
modbus.0	2019-02-26 09:25:49.758	debug	Poll holdingRegs DevID(2) address 1000 - 1 bytes
modbus.0	2019-02-26 09:25:49.693	debug	Poll inputRegs DevID(2) address 2102 - 23 bytes
modbus.0	2019-02-26 09:25:49.601	debug	Poll inputRegs DevID(2) address 2006 - 53 bytes
modbus.0	2019-02-26 09:25:49.597	debug	Poll device 2

Jetzt hätte ich dazu ein paar Fragen:

1. Kann man die Zeit zwischen den Requests irgendwo einstellen. Also z.b. die Zeit zwischen Poll Input-Adress 2006 und Input-Adress 2102. Mein Client will eine definierte Wartezeit zwischen seiner Antwort und einer neuen Anfrage. Evtl. ist das auch der Grund für die Timeouts, wenn der Master manchmal zu schnell ist.

2. Eigentlich will ich die Holding Register nur schreiben.
   Dazu erschließt sich mir die Einstellungen Poll, WP und CW im Reiter "Holding Register" nicht. Ich dachte wenn ich Poll abwähle liest der Adapter die Register nicht mehr. Allerdings wird damit im iobroker das ganze Objekt gelöscht.
   Was ist der Unterschied von WP (schreibe bei Änderung?) zu CW (schreibe zyklsich?)? Es wird irgendwie immer bei Änderung geschrieben. Auch hier könnte ein Timing Problem auftreten.

Vielen Dank schon mal im vorraus für die Antworten.