NEWS
Kopie von ioBroker auf einen Slave-RPI 4
-
@thomas-braun
Ja nur habe ich bereits diverse instanzen und wollte die Geräte nicht neu verbinden müssen sondern einfach so auf den Slave übertragen.@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Bitte verzichtet auf Chat-Nachrichten, denn die Handhabung ist grauenhaft !
Produktiv: RPi 2 mit S.USV, HM-MOD-RPI und SLC-USB-Stick mit root fs -
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
@paul53 sagte:
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Wie gesagt bin ich was die piVCCU angeht da etwas anderer Meinung.
Was nutzt mir die piVCCU auf dem Master im Stahl-Serverschrank im Keller?Auch mein zweiter Slave für Smartmeter ist nicht "nice-To-have" muss aber für den Lesekopf im Zählerschrank hängen (ja, inzwischen gäbe es dafür auch andere Lösungen)
Mir gingen vielmehr Instanzen durch den Kopf, an denen noch "Zentralen" per USB angedockt sind.
Aber auch da kann es wegen der Lage notwendig sein diese auf einen Slave zu verlagernkein Support per PN! - Fragen im Forum stellen - es gibt fast nichts, was nicht auch für andere interessant ist.
Benutzt das Voting rechts unten im Beitrag wenn er euch geholfen hat.
der Installationsfixer: curl -fsL https://iobroker.net/fix.sh | bash -
-
@paul53 sagte:
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Wie gesagt bin ich was die piVCCU angeht da etwas anderer Meinung.
Was nutzt mir die piVCCU auf dem Master im Stahl-Serverschrank im Keller?Auch mein zweiter Slave für Smartmeter ist nicht "nice-To-have" muss aber für den Lesekopf im Zählerschrank hängen (ja, inzwischen gäbe es dafür auch andere Lösungen)
Mir gingen vielmehr Instanzen durch den Kopf, an denen noch "Zentralen" per USB angedockt sind.
Aber auch da kann es wegen der Lage notwendig sein diese auf einen Slave zu verlagern -
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@thomas-braun
Ja nur habe ich bereits diverse instanzen und wollte die Geräte nicht neu verbinden müssen sondern einfach so auf den Slave übertragen.ääääähhhhm
Bitte alle Informationen auf den Tisch!Von welchen Geräten redest du?
Da könnte doch etwas sein.Trotzdem solltest du erst einmal den Raspi, den du als Slave nutzen willst aufsetzen wie ich es schrieb
Dann kanst du dich ja nochmal vor der Kopplung hier melden@homoran
Ich rede von den diversen Sensoren, leuchten, saugroboter & co welche ich als instanz bereits drinnen habe und dachte die die ich am Slave laufen lassen möchte dort nicht neu konfigurieren zu müssen@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Würdest du es auch empfehlen, wenn es so wie bei mir ist? Habe am jetzigen pi den conbeestick per usb, die SSD via USB und hätte dann auch den HMIP Stick per USB - nicht dass die sich irgendwie stören?
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
-
@homoran
Ich rede von den diversen Sensoren, leuchten, saugroboter & co welche ich als instanz bereits drinnen habe und dachte die die ich am Slave laufen lassen möchte dort nicht neu konfigurieren zu müssen@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Würdest du es auch empfehlen, wenn es so wie bei mir ist? Habe am jetzigen pi den conbeestick per usb, die SSD via USB und hätte dann auch den HMIP Stick per USB - nicht dass die sich irgendwie stören?
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
-
@homoran
Ich rede von den diversen Sensoren, leuchten, saugroboter & co welche ich als instanz bereits drinnen habe und dachte die die ich am Slave laufen lassen möchte dort nicht neu konfigurieren zu müssen@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: wollte die Geräte nicht neu verbinden müssen
Da ein Slave nicht ohne Master funktioniert (gemeinsame Datenbanken auf dem Master), würde ich alles, was funktionieren muss, auf dem Master installieren (incl. piVCCU) und das, was "nice to have" ist, auf dem Slave.
Würdest du es auch empfehlen, wenn es so wie bei mir ist? Habe am jetzigen pi den conbeestick per usb, die SSD via USB und hätte dann auch den HMIP Stick per USB - nicht dass die sich irgendwie stören?
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen
-
@igor123 sagte: die SSD via USB
Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD via USB
Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.dem Conbee habe ich ein qualitatives langes USBKabel spendiert und hängt an USB 2.0
SSD ist am 3.0 direkt mit einen kurzen kabel drauf.
wegen störung dachte ich eher dass die SSD dem HMIP-Stick probleme machen könnte da direkt daneben@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen
Um eben diverses Logging zu betreiben und dafür nicht den Master-Pi überfordern zu müssen.
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD via USB
Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.dem Conbee habe ich ein qualitatives langes USBKabel spendiert und hängt an USB 2.0
SSD ist am 3.0 direkt mit einen kurzen kabel drauf.
wegen störung dachte ich eher dass die SSD dem HMIP-Stick probleme machen könnte da direkt daneben@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen
Um eben diverses Logging zu betreiben und dafür nicht den Master-Pi überfordern zu müssen.
-
@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD via USB
Per USB 3, ohne dass Zigbee gestört wird?
Zigbee funkt auf 2,4 GHz, HmIP auf 868 MHz.dem Conbee habe ich ein qualitatives langes USBKabel spendiert und hängt an USB 2.0
SSD ist am 3.0 direkt mit einen kurzen kabel drauf.
wegen störung dachte ich eher dass die SSD dem HMIP-Stick probleme machen könnte da direkt daneben@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Der Montageort wäre mir nicht wichtig, in dem Fall wäre der Slave im selben raum wie der Master
dann stellt sich wirklich die Frage warum bei einem Pi4 mit 8GB RAM noch einen Slave aufbauen
Um eben diverses Logging zu betreiben und dafür nicht den Master-Pi überfordern zu müssen.
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
dafür nicht den Master-Pi überfordern zu müssen.
das solltest du nicht schaffen, wenn dein
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
diverses Logging zu betreiben
nicht äußerst extrem wird
ich habe einen Pi4 mit 2GB und meine täglichen logdateien darauf sind etwa 2GB groß.
Da schmunzelt der Pi nur -
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
dafür nicht den Master-Pi überfordern zu müssen.
das solltest du nicht schaffen, wenn dein
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
diverses Logging zu betreiben
nicht äußerst extrem wird
ich habe einen Pi4 mit 2GB und meine täglichen logdateien darauf sind etwa 2GB groß.
Da schmunzelt der Pi nur@homoran
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
Da habe ich nämlich bemerkt dass dem Pi4 trotz 8GB rasch in puste ausgeht und alles langsamer wird.@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD dem HMIP-Stick probleme machen könnte da direkt daneben
Dann spende dem HMIP-Stick auch ein ausreichend langes, gut geschirmtes USB-Kabel.
Dann werde ich wohl den Master mit PIVCCU versehen und den neuen PI rein als Slave.
Nur die frage.. wie installiere ich pivccu zusätzlich bei einem bereits laufenden system?
-
@homoran
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
Da habe ich nämlich bemerkt dass dem Pi4 trotz 8GB rasch in puste ausgeht und alles langsamer wird.@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD dem HMIP-Stick probleme machen könnte da direkt daneben
Dann spende dem HMIP-Stick auch ein ausreichend langes, gut geschirmtes USB-Kabel.
Dann werde ich wohl den Master mit PIVCCU versehen und den neuen PI rein als Slave.
Nur die frage.. wie installiere ich pivccu zusätzlich bei einem bereits laufenden system?
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
was hat das denn damit zu tun?
In der vis wird nichts geloggt
oder meinst du die Darstellung der geloggten (gespeicherten) Daten per Flot o.ä,?@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Da habe ich nämlich bemerkt dass dem Pi4 trotz 8GB rasch in puste ausgeht und alles langsamer wird.
dann liegt das woanders dran.
Möglicherweise an der Datenbank, der Geschwindigkeit der SD-Karte/Verbindung zu SSD oder der zu hohen Auflösung und damit verbundenen Rechenarbeit beim Berechnen der Graphen -
@homoran
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
Da habe ich nämlich bemerkt dass dem Pi4 trotz 8GB rasch in puste ausgeht und alles langsamer wird.@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: die SSD dem HMIP-Stick probleme machen könnte da direkt daneben
Dann spende dem HMIP-Stick auch ein ausreichend langes, gut geschirmtes USB-Kabel.
Dann werde ich wohl den Master mit PIVCCU versehen und den neuen PI rein als Slave.
Nur die frage.. wie installiere ich pivccu zusätzlich bei einem bereits laufenden system?
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
was hat das denn damit zu tun?
In der vis wird nichts geloggt
oder meinst du die Darstellung der geloggten (gespeicherten) Daten per Flot o.ä,?@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Da habe ich nämlich bemerkt dass dem Pi4 trotz 8GB rasch in puste ausgeht und alles langsamer wird.
dann liegt das woanders dran.
Möglicherweise an der Datenbank, der Geschwindigkeit der SD-Karte/Verbindung zu SSD oder der zu hohen Auflösung und damit verbundenen Rechenarbeit beim Berechnen der Graphen@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
was hat das denn damit zu tun?
In der vis wird nichts geloggt
oder meinst du die Darstellung der geloggten (gespeicherten) Daten per Flot o.ä,?Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund sein -
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
was hat das denn damit zu tun?
In der vis wird nichts geloggt
oder meinst du die Darstellung der geloggten (gespeicherten) Daten per Flot o.ä,?Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund sein@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund seinkannst du da mal Fakten zeigen?
Was ist Auflösung (für dich)?
was ist schwitzen?Wenn du da "unmögliche" Einstellungen nutzst, wird auch ein NUCi5 nicht unbedingt besser sein, eine Multihost Installation schon gar nicht
-
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund seinkannst du da mal Fakten zeigen?
Was ist Auflösung (für dich)?
was ist schwitzen?Wenn du da "unmögliche" Einstellungen nutzst, wird auch ein NUCi5 nicht unbedingt besser sein, eine Multihost Installation schon gar nicht
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund seinkannst du da mal Fakten zeigen?
Was ist Auflösung (für dich)?
was ist schwitzen?Wenn du da "unmögliche" Einstellungen nutzst, wird auch ein NUCi5 nicht unbedingt besser sein, eine Multihost Installation schon gar nicht
Sobald ich dazu komme kann ich nachschauen und genaueres schreiben
Grob gesagt wird ein am Vis via flot der Temperaturverlauf aller Thermostate gleichzeitig angezeigt. Aktualisierung erfolg alle 5 min. Und beim aktualisieren läuft der pi durchaus auf ca 90% Auslastung. Davor ca 20-30% -
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Auch bei dem das logging aktiv beim VIS angezeigt wird ?
was hat das denn damit zu tun?
In der vis wird nichts geloggt
oder meinst du die Darstellung der geloggten (gespeicherten) Daten per Flot o.ä,?Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund sein@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.Läuft die graphische Ausgabe auch über den Pi? Also volles Desktop-Geschirr aufgefahren?
-
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund seinkannst du da mal Fakten zeigen?
Was ist Auflösung (für dich)?
was ist schwitzen?Wenn du da "unmögliche" Einstellungen nutzst, wird auch ein NUCi5 nicht unbedingt besser sein, eine Multihost Installation schon gar nicht
Sobald ich dazu komme kann ich nachschauen und genaueres schreiben
Grob gesagt wird ein am Vis via flot der Temperaturverlauf aller Thermostate gleichzeitig angezeigt. Aktualisierung erfolg alle 5 min. Und beim aktualisieren läuft der pi durchaus auf ca 90% Auslastung. Davor ca 20-30% -
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.Läuft die graphische Ausgabe auch über den Pi? Also volles Desktop-Geschirr aufgefahren?
@thomas-braun sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.Läuft die graphische Ausgabe auch über den Pi? Also volles Desktop-Geschirr aufgefahren?
Nö, ein ipad wird dafür verwendet
-
@igor123 sagte: Temperaturverlauf aller Thermostate gleichzeitig angezeigt.
Über welchen Zeitbereich?
Es werden jedes mal viele Daten aus der History-Datenbank ausgelesen, was den Pi entsprechend fordert.@paul53 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte: Temperaturverlauf aller Thermostate gleichzeitig angezeigt.
Über welchen Zeitbereich?
Es werden jedes mal viele Daten aus der History-Datenbank ausgelesen, was den Pi entsprechend fordert.Sry vergessen zu schreiben
1 monat wird angezeigt -
@homoran sagte in Kopie von ioBroker auf einen Slave-RPI 4:
@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Ich glaub es liegt eher an der anzeige via flot
Kaum rufe ich die angezeige auf schon beginnt der pi zum schwitzen.
Ich gebe zu ich nutze die höheren Auflösungen. Und dementsprechend wird das wohl der Grund seinkannst du da mal Fakten zeigen?
Was ist Auflösung (für dich)?
was ist schwitzen?Wenn du da "unmögliche" Einstellungen nutzst, wird auch ein NUCi5 nicht unbedingt besser sein, eine Multihost Installation schon gar nicht
Sobald ich dazu komme kann ich nachschauen und genaueres schreiben
Grob gesagt wird ein am Vis via flot der Temperaturverlauf aller Thermostate gleichzeitig angezeigt. Aktualisierung erfolg alle 5 min. Und beim aktualisieren läuft der pi durchaus auf ca 90% Auslastung. Davor ca 20-30%@igor123 sagte in Kopie von ioBroker auf einen Slave-RPI 4:
Grob gesagt wird ein am Vis via flot der Temperaturverlauf aller Thermostate gleichzeitig angezeigt. Aktualisierung erfolg alle 5 min.
das ist überhaupt kein Problem...:
(hab das mal auf die Schnelle genommen)... außer die (zeitliche und grafische) Auflösung des Flots ist unterirdisch.
soll übertrieben heißen:- Messwerte alle 10 Sekunden von 100 Thermostaten
- Darstellung von 4 Wochen
Dann müssen alle diese Werte aus den Datenreihen in History (??) ausgelesen werden, Entsprechend auf die Anzahl Pixel im Grafen geglättet werden und an den Chart geschickt werden.
Das Auslesen und Berechnen der Werte für die Darstellung verbraucht die Rechenleistung, nicht das Loggen
EDIT:
Die anderen waren fauler und dadurch schneller :joy:
666
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge