NEWS
S7 Adapter lief Amok
-
Hallo,
heute Morgen kamen über 2 Stunden Meldungen, dass der S7 Adapter Datenpunkte (Objekte) getriggert hat.Das hatte zur Folge, dass Scripte, welche die Datenpunkte beobachteten, wie verückt das Licht hin und her schalteten.
In den Log-Dateien ist Folgendes, für den Zeitpunkt als es losging, zu finden:
iobroker Log:
! ```
019-02-08 05:06:15.429 - [31merror[39m: s7.0 DB write error. Code #655470 2019-02-08 05:06:18.428 - [33mwarn[39m: s7.0 DBRead error[DB 1:0 - 3]: code: 0xa006e 2019-02-08 05:06:18.429 - [33mwarn[39m: s7.0 Poll error count: 1 code: 0xa006e 2019-02-08 05:06:21.428 - [31merror[39m: s7.0 DB write error. Code #655470 2019-02-08 05:06:22.441 - [32minfo[39m: harmony.0 [DISCOVER] Discovered Wohnzimmer (192.168.2.103) and will try to connect 2019-02-08 05:06:24.428 - [33mwarn[39m: s7.0 DBRead error[DB 1:0 - 3]: code: 0xa006e 2019-02-08 05:06:24.428 - [33mwarn[39m: s7.0 Poll error count: 2 code: 0xa006e 2019-02-08 05:06:26.195 - [32minfo[39m: nut.0 Start NUT update 2019-02-08 05:06:26.199 - [32minfo[39m: nut.0 All Nut values set 2019-02-08 05:06:27.316 - [32minfo[39m: javascript.0 script.js.Scripte.Beleuchtung: Mitte Links 2019-02-08 05:06:27.316 - [32minfo[39m: javascript.0 script.js.Scripte.Beleuchtung: Mitte Beide[/code]
! im syslog:
! >![spoiler]~~[code]~~Feb 8 05:06:19 iobroker kernel: [1104542.564162] ------------[ cut here ]------------ Feb 8 05:06:19 iobroker kernel: [1104542.564203] WARNING: CPU: 0 PID: 0 at /build/linux-ttVKu9/linux-4.9.88/net/sched/sch_generic.c:316 dev_watchdog+0x1f4/0x200 Feb 8 05:06:19 iobroker kernel: [1104542.564216] NETDEV WATCHDOG: ens18 (e1000): transmit queue 0 timed out Feb 8 05:06:19 iobroker kernel: [1104542.564229] Modules linked in: nfnetlink_queue nfnetlink_log nfnetlink bluetooth rfkill joydev sg shpchp pcspkr evdev serio_raw virtio_balloon bochs_drm ttm drm_kms_helper drm button nfsd auth_rpcgss oid_registry nfs_acl lockd grace sunrpc parport_pc ppdev lp parport ip_tables x_tables autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb xts lrw gf128mul ablk_helper cryptd aes_i586 mbcache sr_mod cdrom ata_generic hid_generic usbhid hid sd_mod virtio_scsi psmouse ata_piix floppy ehci_pci libata scsi_mod virtio_pci i2c_piix4 virtio_ring virtio e1000 uhci_hcd ehci_hcd usbcore usb_common Feb 8 05:06:19 iobroker kernel: [1104542.564294] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.9.0-6-686-pae #1 Debian 4.9.88-1+deb9u1 Feb 8 05:06:19 iobroker kernel: [1104542.564309] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 Feb 8 05:06:19 iobroker kernel: [1104542.564311] f7433ed8 cb2f7652 f7433eec 00000000 cb067a6a cb71f6cc f7433f0c 00000000 Feb 8 05:06:19 iobroker kernel: [1104542.564316] cb71f708 0000013c cb4e1684 0000013c 00000009 cb4e1684 ef8b9da2 f76ba000 Feb 8 05:06:19 iobroker kernel: [1104542.564320] 000004e2 f7433ef8 cb067ad6 00000009 00000000 f7433eec cb71f6cc f7433f0c Feb 8 05:06:19 iobroker kernel: [1104542.564325] Call Trace: Feb 8 05:06:19 iobroker kernel: [1104542.564327] <irq> Feb 8 05:06:19 iobroker kernel: [1104542.564330] [<cb2f7652>] ? dump_stack+0x55/0x73 Feb 8 05:06:19 iobroker kernel: [1104542.564333] [<cb067a6a>] ? __warn+0xea/0x110 Feb 8 05:06:19 iobroker kernel: [1104542.564336] [<cb4e1684>] ? dev_watchdog+0x1f4/0x200 Feb 8 05:06:19 iobroker kernel: [1104542.564338] [<cb4e1684>] ? dev_watchdog+0x1f4/0x200 Feb 8 05:06:19 iobroker kernel: [1104542.564340] [<cb067ad6>] ? warn_slowpath_fmt+0x46/0x60 Feb 8 05:06:19 iobroker kernel: [1104542.564342] [<cb4e1684>] ? dev_watchdog+0x1f4/0x200 Feb 8 05:06:19 iobroker kernel: [1104542.564345] [<cb4e1490>] ? dev_deactivate_queue.constprop.28+0x60/0x60 Feb 8 05:06:19 iobroker kernel: [1104542.564348] [<cb0d7383>] ? call_timer_fn+0x33/0x120 Feb 8 05:06:19 iobroker kernel: [1104542.564350] [<cb30d977>] ? find_next_bit+0x17/0x30 Feb 8 05:06:19 iobroker kernel: [1104542.564352] [<cb0d72c4>] ? __next_timer_interrupt+0x94/0xc0 Feb 8 05:06:19 iobroker kernel: [1104542.564354] [<cb4e1490>] ? dev_deactivate_queue.constprop.28+0x60/0x60 Feb 8 05:06:19 iobroker kernel: [1104542.564355] [<cb4e1490>] ? dev_deactivate_queue.constprop.28+0x60/0x60 Feb 8 05:06:19 iobroker kernel: [1104542.564358] [<cb0d76f5>] ? run_timer_softirq+0x1d5/0x420 Feb 8 05:06:19 iobroker kernel: [1104542.564361] [<cb5b9bbc>] ? __do_softirq+0xdc/0x258 Feb 8 05:06:19 iobroker kernel: [1104542.564363] [<cb5b9ae0>] ? __softirqentry_text_start+0x8/0x8 Feb 8 05:06:19 iobroker kernel: [1104542.564365] [<cb024b45>] ? call_on_stack+0x45/0x50 Feb 8 05:06:19 iobroker kernel: [1104542.564366] <eoi> Feb 8 05:06:19 iobroker kernel: [1104542.564368] [<cb06da5d>] ? irq_exit+0xad/0xb0 Feb 8 05:06:19 iobroker kernel: [1104542.564370] [<cb5b96ec>] ? smp_apic_timer_interrupt+0x3c/0x50 Feb 8 05:06:19 iobroker kernel: [1104542.564372] [<cb5b8578>] ? apic_timer_interrupt+0x34/0x3c Feb 8 05:06:19 iobroker kernel: [1104542.564374] [<cb5b6f60>] ? __cpuidle_text_start+0x8/0x8 Feb 8 05:06:19 iobroker kernel: [1104542.564376] [<cb5b7222>] ? native_safe_halt+0x2/0x10 Feb 8 05:06:19 iobroker kernel: [1104542.564377] [<cb5b6f7c>] ? default_idle+0x1c/0xc0 Feb 8 05:06:19 iobroker kernel: [1104542.564379] [<cb0aa725>] ? cpu_startup_entry+0x1a5/0x220 Feb 8 05:06:19 iobroker kernel: [1104542.564382] [<cb812b54>] ? start_kernel+0x39c/0x3b3 Feb 8 05:06:19 iobroker kernel: [1104542.564387] ---[ end trace ab70e731efb8aa75 ]--- Feb 8 05:06:19 iobroker kernel: [1104542.564670] e1000 0000:00:12.0 ens18: Reset adapter Feb 8 05:06:21 iobroker kernel: [1104544.644762] e1000: ens18 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX Feb 8 05:09:00 iobroker systemd[1]: Starting Clean php session files... Feb 8 05:09:00 iobroker systemd[1]: Started Clean php session files. Feb 8 05:09:01 iobroker CRON[30967]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi) Feb 8 05:17:01 iobroker CRON[31130]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 8 05:39:00 iobroker systemd[1]: Starting Clean php session files... Feb 8 05:39:00 iobroker systemd[1]: Started Clean php session files. Feb 8 05:39:01 iobroker CRON[31639]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi) Feb 8 06:09:00 iobroker systemd[1]: Starting Clean php session files... Feb 8 06:09:00 iobroker systemd[1]: Started Clean php session files. Feb 8 06:09:01 iobroker CRON[32315]: (root) CMD ( [ -x /usr/lib/php/sessionclean ] && if [ ! -d /run/systemd/system ]; then /usr/lib/php/sessionclean; fi) Feb 8 06:17:01 iobroker CRON[32474]: (root) CMD ( cd / && run-parts --report /etc/cron.hourly) Feb 8 06:22:55 iobroker kernel: [1109138.698835] device ens18 left promiscuous mode Feb 8 06:24:00 iobroker kernel: [1109203.570481] device ens18 entered promiscuous mode Feb 8 06:25:01 iobroker CRON[463]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )) Feb 8 06:25:01 iobroker systemd[1]: Reloading The Apache HTTP Server. Feb 8 06:25:02 iobroker apachectl[550]: AH00558: apache2: Could not reliably determine the server's fully qualified domain name, using 127.0.1.1\. Set the 'ServerName' directive globally to suppress this message Feb 8 06:25:02 iobroker systemd[1]: Reloaded The Apache HTTP Server. Feb 8 06:25:02 iobroker systemd[1]: Stopping Make remote CUPS printers available locally... Feb 8 06:25:02 iobroker systemd[1]: Stopped Make remote CUPS printers available locally. Feb 8 06:25:02 iobroker systemd[1]: Stopping CUPS Scheduler... Feb 8 06:25:02 iobroker systemd[1]: Stopped CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Closed CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Stopping CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Listening on CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Stopped CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Stopping CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Started CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Started CUPS Scheduler. Feb 8 06:25:02 iobroker systemd[1]: Started Make remote CUPS printers available locally.[/code]</cb812b54></cb0aa725></cb5b6f7c></cb5b7222></cb5b6f60></cb5b8578></cb5b96ec></cb06da5d></eoi></cb024b45></cb5b9ae0></cb5b9bbc></cb0d76f5></cb4e1490></cb4e1490></cb0d72c4></cb30d977></cb0d7383></cb4e1490></cb4e1684></cb067ad6></cb4e1684></cb4e1684></cb067a6a></cb2f7652></irq>
[/spoiler]
! Danach bis zum herunterfahren des Servers wurden immer wieder die Datenpunkte, welche sich auf den S7-Adapter beziehen, getriggert. -
Hallo,
heute traf der Fehler wieder auf. Im Syslog ist was zu finden:
-
Hallo,
ich hatte vor 4 Wochen das gleiche Problem sowie letzte Nacht auch. Hast du schon eine Lösung gefunden?
Als Fehlercode steht 0xa006e bei mir im Log drin. Das komische ist, dass genau 4 Wochen zwischen den Ereignissen liegt bis auf 5 Minuten Unterschied. Was hast du denn für eine Steuerung dahinter hängen? Ich hab mehrere Siemens S7 Stationen sowie eine Vipa und nur bei der Vipa kommt dies vor.Gruß Cristian
-
Moin,
so wie es aussieht, war da ein größeres Problem "Reconnection to DB", welches auch schon hier im Forum behandelt wurde. Allerdings ohne passende Lösung.
Klingt bald so, als ob die Netzwerkkarte des VM-Debians flöten geht. Ob es an Proxmox oder dem Debian liegt, kann ich nicht sagen.Ich habe als Workaround einen zusätzlichen Datenpunkt in der Logo angelegt, welcher normal nie getriggert wird. Kommt dieser mal auf true, startet das VM-Debian mit ioBroker neu.
Ich tippe aber bald auf Proxmox, da unter ESXI sowas nie passiert ist.
Ich spiele mit dem Gedanken, ein natives Linux (Debian oder Ubuntu) auf dem Nuc zu installieren und Proxmox wegzulassen. Allerdings weiß ich noch nicht, wie ich das dann bequem mit den Backups löse.Was für ein System hast Du? Auch Proxmox oder was anderes?
-
Hallo,
es ist am Wochenende mal wieder passiert. Das komische ist halt, es passiert immer zwischen 4:00 und 4:14 und das etwa alle 4 Wochen. Ich hab ein 64bit Linux System. Sobald ich den Adapter dann neustarte ist es vorbei. -
@ChristianM
Hallo,
Ich habe mich von proxmox getrennt und fahre iobroker jetzt nativ unter Debian auf einem Intel NUC. Seit dem Systemwechsel ist das Problem noch nicht wieder aufgetreten.Der Nachteil ist ganz klar die schlechtere Möglichkeit von Backups.
-
Ich habe exakt das gleiche Problem. Bezüglich des Reconnect habe ich einen Issue aufgemacht - bisher ohne Resonanz: https://github.com/ioBroker/ioBroker.s7/issues/15
Bei mir prellen die Eingänge: https://forum.iobroker.net/topic/18219/problem-s7-adapter-prellen-bei-netzwerkeingängen/6
==> Hierzu habe ich die Entprellzeit des jeweiligen SQL-Datenpunkts auf 1000ms gesetzt. Bisher ist es nicht mehr aufgetreten.Und Datenpunkte setzen sich selbstständig: https://forum.iobroker.net/topic/20504/problem-datenpunkte-setzten-sich-selstständig-im-vis
==> Hier bin ich mir nicht sicher. Ich vermute, dass, wenn ich beim Laden des VIS im Fully Kioskbrowser schon irgendwo mit den Finger hintippe, dies später als Eingabe gewertet wird. Kann das aber nicht so richtig reproduzieren. Seitdem ich jedoch das VIS "vorsichtig" öffne tritt es nicht mehr auf.Promox kann ich zu 100% ausschließen. Ich hatte exakt die selben Fehler auf einem Raspi.
-
Bei mir waren im Systemlog zeitgleich Netzwerkfehler aufgetreten. Ob es an Proxmox lag oder das Debian darunter - ???
Im neuen System habe ich das Netzwerk anders angebunden. Der Networkmanager soll die Verbindung überwachen und wohl auch neu starten können. Allerdings habe ich auch Probleme mit dem Netzwerk beim Einrichten des NUCs gehabt.Beim Wechsel von Ubuntu, was ich zuerst getestet hatte, auf Debian war plötzlich die Netzwerkkarte weg. Neustarts hatten nicht gereicht. Erst ein stromlosmachen des NUCs erweckte den LAN-Anschluss wieder zum Leben.
Ein Prellen habe ich nicht bemerkt.
-
Moin,
gestern stand das Update für die FritzBox an. Währenddessen wurden wieder alle Datenpunkte getriggert und somit Festbeleuchtung im Haus.
Die Verbindung ioBroker<>Logo! läuft über den Switch der FritzBox.
Heute Morgen wollte ich das nachstellen. Egal, ob ich die Netzwerkkabel und / oder das DSL-Kabel ziehe oder die FritzBox neu starte - der Fehler tritt nicht auf. Somit sehr schwierig zu finden.
-
@ChristianM sagte in S7 Adapter lief Amok:
Hallo,
Das komische ist halt, es passiert immer zwischen 4:00 und 4:14 und das etwa alle 4 Wochen.Nachts ? zur selben Zeit ?
äh, blöde Idee, aber was ist mit einer möglichen Zwangstrennung seitens des Providers ? -
Seit einigen Tagen tritt der Fehler bei mir nicht mehr auf. Ich habe nichts bewusstes an der gesamten Anlage verändert...
-
@George_Best said in S7 Adapter lief Amok:
Seit einigen Tagen tritt der Fehler bei mir nicht mehr auf. Ich habe nichts bewusstes an der gesamten Anlage verändert...
Was ware es denn?
Ich habe gerade das Problem das die Analogen werte mir bei den Digitalen dazwischen funken...
Bis jetzt habe ich aber nichts dazu gefunden....