piVCCU übernimmt ip adresse nicht

Virtualisierte CCU für Raspberry Pi und Clones

Moderator: Co-Administratoren

Antworten
VersusF
Beiträge: 2
Registriert: 05.09.2019, 12:23
Hat sich bedankt: 2 Mal

piVCCU übernimmt ip adresse nicht

Beitrag von VersusF » 05.09.2019, 14:37

Hallo zusammen,
ich bin von diesem Projekt sehr begeistert und habe mich an der Installation versucht.
Mein Ziel ist einen OrangePi +2e mit piVCCU3 und ioBroker mit dem HM-MOD-RPI-PCB am Laufen zu haben.

Momentan scheitert es schon am piVCCU.
Die WebUI ist nicht erreichbar

Begonnen habe ich mit Armbian Stretch (Armbian_5.83_Orangepiplus2e_Debian_stretch_next_4.19.38).
Ich bin die manuelle Anleitung über GitHub gefolgt und habe, wenn ich sonst nichts vergessen habe nur den letzten Befehl zur statischen IP aus Punkt 6 ausgelassen, da dieser optional sein sollte. (Soll über den DHCP-Server geregelt werden)
Über den DHCP-Server wird eine IP(192.168.33.30 ) vergeben und für die MAC(02:81:7c:b4:bc:f2) reserviert. Über diese IP ist der OPi auch über Putty erreichbar. (In meinem DHCP-Server müssen MAC erst freigeschaltet werden, damit sie Netzwerkzugriff erhalten)

sudo pivccu-info ergibt folgende Ausgabe

Code: Alles auswählen

root@orangepiplus2e:~# sudo pivccu-info
piVCCU version: 3.47.15-30
Kernel modules: Available
Raw UART dev:   Available
HMRF Hardware:  HM-MOD-RPI-PCB
HMIP Hardware:  HM-MOD-RPI-PCB
Board serial:   PEQ0174376
Radio MAC:      0x671289
SGTIN:          3014F711A061A7D8A98C1128
State:          RUNNING
PID:            1237
IP:             169.254.9.24
CPU use:        49.39 seconds
BlkIO use:      55.92 MiB
Memory use:     145.77 MiB
KMem use:       4.18 MiB
Link:           vethpivccu
 TX bytes:      290.51 KiB
 RX bytes:      1.23 MiB
 Total bytes:   1.51 MiB
Woher bezieht er die IP: 169.254.9.24?


ifconfig gibt folgende Ausgabe:

Code: Alles auswählen

root@orangepiplus2e:~# ifconfig
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.33.30  netmask 255.255.255.0  broadcast 192.168.33.255
        inet6 fe80::fdd8:84a6:6782:1659  prefixlen 64  scopeid 0x20<link>
        ether 02:81:7c:b4:bc:f2  txqueuelen 1000  (Ethernet)
        RX packets 22953  bytes 1498999 (1.4 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1057  bytes 104921 (102.4 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether 02:81:7c:b4:bc:f2  txqueuelen 1000  (Ethernet)
        RX packets 26814  bytes 7376442 (7.0 MiB)
        RX errors 0  dropped 106  overruns 0  frame 0
        TX packets 3641  bytes 526266 (513.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 40

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vethpivccu: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fcc1:aeff:fefb:fcbf  prefixlen 64  scopeid 0x20<link>
        ether fe:c1:ae:fb:fc:bf  txqueuelen 1000  (Ethernet)
        RX packets 1005  bytes 342679 (334.6 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 22699  bytes 1494751 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 12:81:7c:b4:bc:f2  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0


Benutzeravatar
deimos
Beiträge: 5396
Registriert: 20.06.2017, 10:38
System: Alternative CCU (auf Basis OCCU)
Wohnort: Leimersheim
Hat sich bedankt: 121 Mal
Danksagung erhalten: 957 Mal
Kontaktdaten:

Re: piVCCU übernimmt ip adresse nicht

Beitrag von deimos » 05.09.2019, 15:28

Hi,

der Container holt sich ebenfalls eine IP per DHCP. Wenn er die nicht erhält, dann wird eine Linklocal Adresse aus dem Bereich 169.254.0.0/16 verwendet.
Die MAC Adresse des Container kannst du erhalten mit

Code: Alles auswählen

sudo pivccu-attach ifconfig eth0
Viele Grüße
Alex

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 71 Mal

Re: piVCCU übernimmt ip adresse nicht

Beitrag von klassisch » 05.09.2019, 18:23

Habe auch einen Orange Pi Plus 2e mit piVCCU3 und abgesetztem Funkmodul mit spezieller rauscharmen Versorgung.
Ebenfalls alles from the scratch aufgesetzt, kein fertiges Image. Geht beim OPi mit Arbian und eMMC auch ganz gut und flott.
Hatte von der CCU2 gewechselt und auch deren IP Adresse übernommen. Das habe ich über die Fritzbox und deren binding von IP Adresse an MAC gemacht (Diesem Gerät immer dieselbe IP zuordnen).
Funktioniert super und der OPi langweilt sich.
Etwas ioBroker kann man da sicher noch mit draufpacken.
Hatte meinen ioBroker auch auf so einem OPi, allerdings auf einem separaten.
Geht auch ganz gut. Allerdings wurde bei mir dann die Last/Datenrate irgendwann mal grenzwertig und in Folge startete der history Adapter ab und an neu. Habe deshalb ioBroker auf ein gebrauchtes Notebook umgestellt. Funktioniert sehr gut.

VersusF
Beiträge: 2
Registriert: 05.09.2019, 12:23
Hat sich bedankt: 2 Mal

Re: piVCCU übernimmt ip adresse nicht

Beitrag von VersusF » 06.09.2019, 10:38

deimos hat geschrieben:
05.09.2019, 15:28
Hi,

der Container holt sich ebenfalls eine IP per DHCP. Wenn er die nicht erhält, dann wird eine Linklocal Adresse aus dem Bereich 169.254.0.0/16 verwendet.
Die MAC Adresse des Container kannst du erhalten mit

Code: Alles auswählen

sudo pivccu-attach ifconfig eth0
Viele Grüße
Alex
Dank dir!

Kurz die MAC freigeschaltet und es lief direkt an :)
klassisch hat geschrieben:
05.09.2019, 18:23
Habe auch einen Orange Pi Plus 2e mit piVCCU3 und abgesetztem Funkmodul mit spezieller rauscharmen Versorgung.
Ebenfalls alles from the scratch aufgesetzt, kein fertiges Image. Geht beim OPi mit Arbian und eMMC auch ganz gut und flott.
Hatte von der CCU2 gewechselt und auch deren IP Adresse übernommen. Das habe ich über die Fritzbox und deren binding von IP Adresse an MAC gemacht (Diesem Gerät immer dieselbe IP zuordnen).
Funktioniert super und der OPi langweilt sich.
Etwas ioBroker kann man da sicher noch mit draufpacken.
Hatte meinen ioBroker auch auf so einem OPi, allerdings auf einem separaten.
Geht auch ganz gut. Allerdings wurde bei mir dann die Last/Datenrate irgendwann mal grenzwertig und in Folge startete der history Adapter ab und an neu. Habe deshalb ioBroker auf ein gebrauchtes Notebook umgestellt. Funktioniert sehr gut.
Je nachdem wie negativ die Störung/Reichweite ausfällt, ist eine neue Antenne auch angedacht.

Was meinst du mit Last/Datenrate?
Eigentlich sollte der OPi doch für beide Dienste ausreichend sein. (2gb RAM, eMMC Speicher, "GigaBit" LAN)

klassisch
Beiträge: 3974
Registriert: 24.03.2011, 04:32
System: Alternative CCU (auf Basis OCCU)
Hat sich bedankt: 110 Mal
Danksagung erhalten: 71 Mal

Re: piVCCU übernimmt ip adresse nicht

Beitrag von klassisch » 07.09.2019, 05:20

[Teil-OT, da sehr ioBroker und HW-lastig - manchem wohl auch lästig :D ]
VersusF hat geschrieben:
06.09.2019, 10:38
Was meinst du mit Last/Datenrate?
Es gibt Adapter, deren Defaulteinstellung ich mittlerweile als paranoid bezeichnen würde. Der im Prinzip nützliche info Adapter greift in der Defaulteinstellung alle paar Sekunden eine große Menge an Systemdaten ab. Ähnlich auch ein Systeminfo-Adapter. Wenn man dann mal pauschal alle Datenpunkte in die History abonniert, kommen diese Datenpunkte auch dazu und werden entsprechend häufig abgespeichert. Und das kann dann den OPi zeitweise an die Grenzen bringen. Das ist bei mir passiert, was sich in sporadischen history-Restarts ausgewirkt hat. Da beim Restart wieder alle Datenabonnements neu aufgesetzt werden, wird das Problem eher größer. Da beim headless Betrieb auf einem für mich fremden Linux-OS die Ursachenforschung für mich eher unpraktisch war, bin ich mit ioBroker auf einen wegen einer anderen Applikation ohnehin laufenden Win-Rechner umgezogen. Der hat natürlich mehr Rechenleistung und steckt das locker weg. Und durch die gewohnte Windows Umgebung mit den gewohnten Tools habe ich dann sozusagen en passant und ohne explizit danach zu suchen die Störenfriede gefunden.
Den systeminfo Adapter habe ich abgeschaltet und den info-Adapter runterparametriert. Die Abtastszeiten auf max gestellt - was meiner Meinung nach noch immer zu häufig ist - und die Speicherung in history stark gefiltert. Also nur bei entsprechend großen Wertesprüngen wird ein Wert gespeichert. Das hat die Datenmenge deutlich erniedrigt und reicht für eine Routineüberwachung des Systems völlig aus.
Das so parametrierte System wäre wahrscheinlich auch auf dem OPi wieder stabil. Und die piVCCU-Last ist eh gering. Aus Rechenzeitgründen würde das wahrscheinlich gehen. Aber ich brauche wegen der Antennen eh verschiedenen Standorte. Habe an ioBroker RFLink mit 433MHz angeschlossen und diese Antenne hat nicht mehr an die gleiche Position der 868MHz Antenne gepaßt. Ausserdem bin ich jetzt mit ioBroker auf dem Win Rechner und das hat sich für mich bewährt. Die Pflege fällt mir leichter und wird von der ioBroker Community durch einen entsprechenden Installer gut unterstützt.
VersusF hat geschrieben:
06.09.2019, 10:38
Eigentlich sollte der OPi doch für beide Dienste ausreichend sein. (2gb RAM, eMMC Speicher, "GigaBit" LAN)
Wie oben geschrieben: Wenn man die Ressourcen und die Aktualisierungszeiten und history-Datemengen etwas im Auge behält wird man recht weit kommen. Man muß halt etwas mehr aufpassen, was man tut. Ich habe meine Daten auf ein billige SSD via USB 2.0 Adapter geschrieben. Dadurch wird das eMMC entlastet und man kommt auch bei einem defekten OPi noch immer bequem an die Daten ran.
Und da gibt es noch einen etwas gegenläufigen Effekt. Viele Nutzer und natürlich besonders auch Entwickler sind auf kräftigere Plattformen umgestiegen. x86, NUCs - oder wie in meinem Fall gebrauchte Notebooks bzw. PCs. Proxmox ist da wohl ein beliebtes Betriebs- und Spielsystem oder eben auch Win. Und dann wird halt automatisch und unabsichtlich immer weniger Rücksicht auf die kleinen Systeme genommen. Wie im richtigen Leben. Ich bin - damals - auch recht lange mit einem Modem und ohne das teure DSL zu recht gekommen. Aber dann wurden die Webseiten immer graphischer, bunter, "schwerer" und die Ladezeiten immer länger. Also wurde das teure DSL unausweichlich. Und mittlerweile stufe ich schnelles Internet als Grundlebensmittel ein - zumindest buchhalterisch.
Diesen Trend sehe ich hier auch. Bei ioBroker allemal und wenn man bei piVCCU noch redmatic o.ä. dazupackt wird das wohl in eine ähnlich Richtung gehen.
Auch @deimos ist ja mit Debmatic einen solchen Schritt - oder Sprung - gegangen. Unterstützt piVCCU aber immer noch vorbildlich - Danke dafür.
Unterm Strich halte ich den OPi noch immer für einen attraktiven Rechner. Für piVCCU allemal perfekt und auch für ioBroker gut geeignet. RasPi hat jetzt aufgeholt und wenn man den mal endlich von einer SSD booten kann, dann hat er wahrscheinlich die Nase vorn. 4GB ist brauchbar. Dann liegt man aber auch schnell bei 70 bis 90 EUR bis alles beisammen ist. Und die richtig starken und noch weniger kompatiblen SBCs rücken dann schnell in eine Region wo ich mit einem refurbished Notebook günstiger unterwegs bin. Mit einem alten "Schubladengerät" aus dem eigenen Altbestand natürlich schon weitaus früher. Eine rationale Begründung für einen SBC > 150 EUR wird sehr schwer. Spieltrieb und wissenschaftliche Neugier wird natürlich gerne akzeptiert, ist aber eigentlich keine wirklich rationale Begründung.

Antworten

Zurück zu „piVCCU“