Orange Pi Plus 2e

[klassisch]

@knopers1 sagte in Orange Pi Plus 2e:

Es fängst ja schon damit an, dass beim Installieren des RFLink-adapters die angegeben Links die zum Download der seriellen Schnittstele notwendig sind, in leere gehen...?

Das ist natürlich schlecht. Das würde mich bei piVCCU auch treffen, wenn ich auf buster updaten würde.

Ich habe zu wenig Ahnung von dem Zeug.

Ich leider auch nicht. Ich frickle zwar schon seit Jahrzehnten an diesen SBC-Linuxen rum, aber auskennen geht anders.

Hattest Du mehr Glück mit den Strech Image?

Unter Stretch lief mein ioBroker incl. RFLink bis in Q1 2019.
Und unter stretch habe ich im piVCCU auch den CUL-Stick über USB angebunden.
Die SSD für die History-Daten lief auch über USB.
Buster habe ich noch nicht im Haus.

Hatte mal - wegen eines USB-Hub-Problems - Schwierigkeiten mit dem USB

Hier meine Notizen dazu

RF-Link bleibt seit ein paar Wochen plötzlich stecken
Was bisher geholfen hat:
- Notebook an RFLink-Mega anschließen (USB)
- Programm d:\tmp\RFLink_v1.1_r48\RFLinkLoader.exe starten
- Logging aktivieren. Nach einigen Sekunden meldet sich der Mega mit einer RFLink Begrüßungsformel
- Wieder zurückstecken an Opi
- ioBroker Instanzen öffnen und serieller Port einstellen: /ttyUSB0
-
Kontrollieren, ob der Mega noch angeschlossen ist:
root@opi2e_ioBroker:~# lsusb
Bus 008 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 004 Device 009: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technolo gy Corp.
Bus 004 Device 010: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter
Bus 004 Device 007: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 004 Device 001: ID 1d6b:1002 Linux Foundation 2.0 root hub
Bus 003 Device 001: ID 1d6b:1002 Linux Foundation 2.0 root hub
Bus 002 Device 002: ID 2537:1066
Bus 002 Device 001: ID 1d6b:1002 Linux Foundation 2.0 root hub
Bus 001 Device 001: ID 1d6b:1002 Linux Foundation 2.0 root hub

Der QinHeng Electronics HL-340 USB-Serial adapter gehört zu einem China-Mega-Clon.

Nächste Schritte:
- Cron zum täglichen Neustart deaktivieren. Cron Definition 3 2 * * * am 2019-01-18 deaktiviert. Hat nichts gebracht, siehe 2018-01-20
- USB Hub incl. Kabel austauschen bzw. umgehen. 2018-01-20: Weg vom USB-Hub, direkt in den Opi gesteckt
- Mega 2650 incl. USB Kabel austauschen

-  
- Hinweise zum Binden von ttyUSB devices: https://wiki.fhem.de/wiki/Mehrere_USB-Ger%C3%A4te_einbinden 
- Listen:
root@opi2e_ioBroker:~# ls -l /dev/serial/by-id
total 0
lrwxrwxrwx 1 root root 13 Dec 29 16:34 usb-1a86_USB2.0-Serial-if00-port0 -> ../.                         ./ttyUSB0

[knopers1]

@klassisch

ich versuche heute mal das Image aus dem Download Bereich mit Armbian Strech mit nodejs 8.15.0 und nmp 6.4.1.
Den JS-Controller kann ich immer noch auf den neusten Stand bringen. Schauen wir mal ob die Adapter funktionieren unter der älteren Konfiguration.

Sollte das mit der alten Kacke funzen, so kann ich es immer noch mit update und upgrade auf die nodejs 10x bringen.
Nicht dass der Fehler wegen der node 10.17.1 verursacht wird.

Am Kabel oder dem Mega 2650 kann es ja nicht liegen. Es läuft zur Zeit mit dem alten Image ohne Probleme.
Dabei habe ich sogar den neusten jscontroller installiert...
Das einzigste was jetzt nur noch den Unterschied ausmacht, sind es die nodejs (8.15.0 zu 10.17.1)

Ich berichte mal... das Gefrickel bringt mich lansam zur Weißglut.

[klassisch]

@knopers1
Auf meinem Windows Rechner laufen nun
Node-Version: 10.16.3
Nodejs-Version: v10.16.3
NPM-Version: 6.9.0

und da geht RFLink

Habe durch Überfliegen des Forums mitbekommen, daß es letztes Jahr ein ziemliches Durcheinander wegen NPM- und Node- Versionen gab.
Das war für mich ein weiterer Grund, mich für den Windows-Installer zu entscheiden. Da bekommt man dann ein funktionierendes kanonisiertes Paket.
Der OPi lief tapfer, solange man die Finger von den Updates gelassen hat. Wenn was passiert ist, dann meistens bei Updates.

[knopers1]

@klassisch
das kann ich Dir sagen.... Mein OPI lief 194 Tage am Stück ohne Reboot bis ich auf die Idee kam, ein Update anzustossen.
An sich funktioniert noch alles mit dem alten jessi taddellos, nur die Frage ist- wie lange noch... Ich kann keine Updates mehr machen. Früher oder später werde ich sowieso installieren müssen.

[knopers1]

@klassisch

habe doch noch den Umzug auf die Orangepi geschaft.
Puhh, mit dem reinstal.sh Script konnte ich doch den /dev/ttsUSB mit dem RF-Link auswählen.
Jetzt muckt nur noch der OPI Adapter mit einem Wert im Log.

No Value found for memory_available 

Dafür läuft alles andere und ist auf dem neusten Stand.

ioBroker-OPiplus2e

Betriebssystem
    linux
Architektur
    arm
CPUs
    4
Geschwindigkeit
    1296 MHz
Modell
    ARMv7 Processor rev 5 (v7l)
RAM
    1.97 GB
System Betriebszeit
    00:45:36
Node.js
    v10.17.0
NPM
    6.11.3
Festplatte Größe
    14.62 GB
Festplatte frei
    12.78 GB
Anzahl der Adapter
    300
Betriebszeit
    00:45:11
Aktive Instanzen
    24
Hostname
    ioBroker-OPiplus2e

login as: pi
pi@192.168.1.100's password:

---

/ _ | _ () _ |__ | |
| | | | |) | || | _) | |
| || | /| | | / /| |
_/|| || || |||

Welcome to Debian Stretch with Armbian Linux 4.19.62-sunxi
System load: 1.92 0.48 0.16 Up time: 0 min
Memory usage: 10 % of 2013MB IP: 192.168.1.100
CPU temp: 39°C
Usage of /: 14% of 15G

Last login: Sun Oct 27 12:02:48 2019 from 192.xxx.1.xx

pi@ioBroker-OPiplus2e:~$

[klassisch]

@knopers1 Glückwunsch, daß alles geklappt hat. Wahrscheinlich wird irgendwann auch mal Buster gehen, das wird man dann irgendwo lesen. Solange auf Stretch alles läuft ist das doch gut. Ich habe auch noch 2 OPis auf Stretch laufen.
Den OPi Adapter kannst Du auch abschalten. Bei Armbian gibt es den armbianmonitor. Wenn ich mich recht erinnere, installiert

armbianmonitor -r 

Einen Monitor, der dann auch Graphen anzeigen kann unter

IP.Adresse.vom.OPi:8888/statistics.html

Ausserdem gibt es unter ioBroker noch den Info-Adapter, der das auch kann und dann auch in die ioBroker Datenbasis (Objekte) schreibt. Ich empfehle eine verhaltene, langsame Updaterate einzustellen und nur das Nötigste auszulesen. Temperatur, freien Speicher. Hüufiges Auslesen schafft unnötige Last und Schreibvorgänge. Und wenn an Deinem System etwas richtig schief läuft, dann siehst Du das auch wenn Du nur alle paar Minuten ausliest. Und das Gezappel dazwischen ist meist uninteressant.
Wenn Du Daten in History wegschreibst, dann empfehle ich Dir dafür eine kleine SSD. Einfache 120GB gibts schon für <20 EUR. 32GB oder 60GB von KingDian tuns für die Daten aber auch. Da gibt es 60GB für ca. 13 EUR - delivered.

Das mit den Updates ist so eine unerfreuliche Sache. Die Linux-Fans schimpfen über die Windows Update-Politik - zu Recht, wie ich meine. Wobei man ab Win 10 1903 das Update um 7 Tage verschieben kann. Aber Linux Updates machen zumindest bei den SBCs auch keinen Spass. Und wenn man dann mal ein Problem hat, dann muß man strampeln. Bei Windows findet man meist schon eine Lösung im Netz.

[knopers1]

@klassisch
besten Dank! Jetzt habe ich alles was ich haben woltte. Alle Werte standen im Info Adapter. Den Opi Adapter habe gelöscht. Danke Dir!

[slonnet]

@tripper sagte in Orange Pi Plus 2e:

Irgendwie muss ich das aber auch ohne lokalen NTP Server hinkriegen. Eine Verbindung nach aussen sollte ja nicht das Problem sein.

EDIT: Hab nun noch einen Versuch mit dem ntpdate Service am laufen. Soweit ich das verstehe habe ich nun 2 Dienste die die Zeit Synchronisieren!? Ich hoffe das klappt und bringt nicht noch mehr Probleme

@tripper
konntest du das Zeitproblem nachhaltig lösen?
Ich habe das gleiche Problem, das die Systemzeit sich nach ca 10 Tagen auf das Datum 01.01.1970 zurücksetzt.

[knopers1]

@slonnet

zeige doch die Ausgabe davon...

systemctl status ntp

[slonnet]

@knopers1 sagte in Orange Pi Plus 2e:

@slonnet

zeige doch die Ausgabe davon...

systemctl status ntp

pi@orangepiplus2e:~$ systemctl status ntp
* ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp; generated; vendor preset: enabled)
   Active: active (running) since Tue 2019-11-05 18:32:59 CET; 12h ago
     Docs: man:systemd-sysv-generator(8)
  Process: 5036 ExecStop=/etc/init.d/ntp stop (code=exited, status=0/SUCCESS)
  Process: 5047 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/ntp.service
           `-5057 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -c /run/ntp.conf.dhcp -

Nov 05 18:32:59 orangepiplus2e systemd[1]: Starting LSB: Start NTP daemon...
Nov 05 18:32:59 orangepiplus2e ntp[5047]: Starting NTP server: ntpd.
Nov 05 18:32:59 orangepiplus2e systemd[1]: Started LSB: Start NTP daemon.
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: proto: precision = 0.833 usec (-20)
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: Listen and drop on 0 v6wildcard [::]:
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: Listen and drop on 1 v4wildcard 0.0.0
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: Listen normally on 2 lo 127.0.0.1:123
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: Listen normally on 3 eth0 192.168.1.2
Nov 05 18:32:59 orangepiplus2e ntpd[5057]: Listening on routing socket on fd #20
lines 1-19/19 (END)

Bitte sehr, sieht für mich als Laie ok aus

[slonnet]

Die Ausgabe von timedatectl macht mich skeptisch!

root@orangepiplus2e:~# timedatectl
      Local time: Wed 2019-11-06 17:26:17 CET
  Universal time: Wed 2019-11-06 16:26:17 UTC
        RTC time: Wed 2019-11-06 16:26:23
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no

Warum läuft die RTC time nach ca 1 Stunde schon um 6 Sekunden vor?
Oder ist das irrelevant, der Opi hat ja keine RTC.

[knopers1]

@slonnet

bei mir sieht es so aus:
So wie es aussieht, läuft alles richtig bei Dir. Hast Du zur Zeit die richtige Uhrzeit? Ich denke ja....

pi@ioBroker-OPiplus2e:~$ timedatectl
      Local time: Mi 2019-11-06 19:30:52 CET
  Universal time: Mi 2019-11-06 18:30:52 UTC
        RTC time: Mi 2019-11-06 18:30:59
       Time zone: Europe/Berlin (CET, +0100)
 Network time on: yes
NTP synchronized: yes
 RTC in local TZ: no
pi@ioBroker-OPiplus2e:~$

pi@ioBroker-OPiplus2e:~$ systemctl status ntp
● ntp.service - LSB: Start NTP daemon
   Loaded: loaded (/etc/init.d/ntp; generated; vendor preset: enabled)
   Active: active (running) since Mon 2019-11-04 03:17:15 CET; 2 days ago
     Docs: man:systemd-sysv-generator(8)
  Process: 1248 ExecStart=/etc/init.d/ntp start (code=exited, status=0/SUCCESS)
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/ntp.service
           └─1264 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 106:111

Nov 04 03:17:19 ioBroker-OPiplus2e ntpd[1264]: Listen normally on 4 eth0 192.168.1.100:123
Nov 04 03:17:19 ioBroker-OPiplus2e ntpd[1264]: Listen normally on 5 eth0 [fe80::8dbd:c112:3637:e465%3]:123
Nov 04 03:17:19 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 144.76.70.233
Nov 04 03:17:20 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 82.64.45.50
Nov 04 03:17:21 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 213.172.105.106
Nov 04 03:17:22 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 185.120.22.12
Nov 04 03:17:23 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 78.46.253.198
Nov 04 03:17:24 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 188.174.253.163
Nov 04 03:17:25 ioBroker-OPiplus2e ntpd[1264]: Soliciting pool server 178.63.247.119
Nov 04 05:14:06 ioBroker-OPiplus2e ntpd[1264]: 188.174.253.163 local addr 192.168.1.100 -> <null>
pi@ioBroker-OPiplus2e:~$

[slonnet]

@knopers1 sagte in Orange Pi Plus 2e:

So wie es aussieht, läuft alles richtig bei Dir. Hast Du zur Zeit die richtige Uhrzeit? Ich denke ja....

Nach einen kompletten Neustart des Systems läuft alles richtig für ca 10 Tage.

Im Fehlerfall sehe ich, das alle Flot Grafiken nur noch gerade Linien zeigen (es wird also nichts mehr geloggt). Ich denke das der SQL Adapter durch das falsche Datum aufhört zu loggen.

Der SSH Zugang geht dann auch nicht mehr!

VIS ist allerdings noch bedienbar.
Habe jetzt als Workaround ein Reboot Knopf in VIS eingebaut, das ich das System zumindest sauber neustarten kann.

Auf Dauer natürlich keinen Lösung!

[knopers1]

@slonnet

hmm, da hängst sich aus einem Grund das System auf.... Das Netzteil an dem Teil kann auch Ärger machen.
Hast Du evtl. ein anderes zum testen da? Hast Du die Software auf der SD Karte, USB, Flash???
Evtl. eine Sicherung vom Vis und das System neu aufsetzen. Könnte auch abhilfe schaffen.

[slonnet]

@knopers1 sagte in Orange Pi Plus 2e:

@slonnet

hmm, da hängst sich aus einem Grund das System auf....

Nein, das System läuft an sich, nur das die Systemzeit überhaupt nicht mehr passt und es zu Folgeproblemen kommt.

Das Netzteil an dem Teil kann auch Ärger machen.

Stimmt, ich habe tatsächlich noch ein anders da!

Hast Du evtl. ein anderes zum testen da?

Ja, noch viel besser, ich habe noch einen zweiten baugleichen Orange Pi da!

Hast Du die Software auf der SD Karte, USB, Flash???

Wie sich das für einen Opi +2e gehört habe ich das System auf dem internen emmc Speicher.

Evtl. eine Sicherung vom Vis und das System neu aufsetzen. Könnte auch abhilfe schaffen.

Das System ist erst gerade neu aufgesetzt! Das ist ja das Traurige!

[knopers1]

@slonnet

naja, wenn Du nicht einmal zeitgleich über SSH zugreifen kannst, ich es etwas mehr als nur die falsche Uhrzeit! Oder? Da schmiert noch mehr im Hintergrund ab.
Macht beide OrangePi den gleichen Ärger? oder hängt andauernt nur einer?

Ich werde Dir an der Stelle nicht weiterhelfen können, es könnte an allem liegen.
Netzteil, Software, Hardware....

[klassisch]

Mit einem richtigen Netzteil, Kühlung und OS läuft der OPi stabil von der eMMC. Auch mit ioBroker. Allerdings hatte ich meine History-Daten nicht auf die eMMC geschrieben, sondern auf eine externe USB-SSD. Da reicht eine billige China SSD "Kingdian" 32GB. Aber heute gibts auch schon 120GB SSD für 17EUR in DE-Shops. 3 EUR für einen USB SSD Adapter dazu und man hat eine gute Lösung.
Ich versorge meine OPi aus einem 15V 1.66A Routernetzteil von Pollin (<2EUR) und einem kleinen DC-DC-Wandler, der aus den 12V die erforderlichen 5V macht. Auf der 5V Seite alles direkt gelötet, nichts gesteckt, nur die 15V gesteckt. Oder aus einem 5V Netzteil entpsrechender Stärke mit dem passenden barrel connector, das ich mal im Abverkauf (Pollin?) erworben habe. Vorsichtshalber noch ein 6.3V 1000µF Elko dran gelötet. Billig, stört nicht und kann helfen.
Armbian OS hole ich direkt bei Armbian. So früh wie möglich auf eMMC umstellen und erst dann fertig einrichten / update / ugrade etc. Danach ioBroker mit dem aktuellen Installer drauf installieren.
Probleme mit dem OPi gabs nur bei Linux Updates, vor allem Kernel Updates oder wenn man zu viele Daten in kurzer Zeit per history-Adapter schreibt.
Meinen ioBroker habe ich ja mittlerweile auf Windows Notebook umgestellt, betreibe aber noch einen OPi mit piVCCU und einen anderen mit einem NUT Server. Beide laufen sehr stabil, wobei die Lasten natürlich auch lächerlich gering sind