NEWS
Vorstellung und Starthilfe- Ersuchen
-
@m-i-b-0 sagte: geht mit der vorhandenen Hardware und ioB schlicht gar nix.
Ein CUL-Adapter auf einem ioBroker-Slave (RasPi mit SCC) sollte funktionieren. Laut hobbyquaker/cul wird der SCC und MAX! unterstützt.
EDIT: Auch der Maxcul-Adapter läuft offenbar mit dem SCC.
... ja, solche Dinge laufen. Aber da ich derzeit zwei RPi mit jeweils drei SCC und einen HMLAN am Laufen habe, würde das bedeuten, das ich mindestens 4 weitere RPi's bräuchte (derzeit faktisch nicht zu bekommen), um zumindest die jetzige Funkabdeckung mit ioB wieder herstellen zu können. Dann hätte ich hier alleine dafür 6 RPi's am Laufen... Unakzeptabel... Und wie ich das dann mit meiner Ölbrenner-Steuerung mache, ist mir im Moment noch so gar nicht klar (den Ölbrenner und die Pumpen macht derzeit ein autarker RPi mit FHEM, welcher über MQTT angebunden ist und so seine Umwelt- und Bedarfsdaten erhält).
Im Grunde ist es sehr schade, das solche Teile wie der BUZZER oder ähnlich modular aufgebaute Multi-Transceiver- Systeme kaum existieren und wenn, nativ von ioB nicht unterstützt werden. Das wäre letztlich die Lösung all meiner Probleme und da würde ich tatsächlich auch Geld in die Hand nehmen. Es wundert mich sogar, das die ioB- Macher/Ihr solcherlei noch gar nicht ins Auge gefasst habt...
Ich hatte es seinerzeit mit Absicht darauf angelegt, nicht für jedes Protokoll jeweils ein eigenes, protokollspezifisches GateWay (CCU, MaxCube, trallalla) zu benötigen. Das macht in meinen Augen keinen Sinn, wenn man sowieso schon eine Software einsetzen kann, welche entsprechende Transceiver nativ unterstützt. FHEM konnte/kann das. Was ich allerdings vor fast 10 Jahren nicht erwartet hatte ist, das sich FHEM zu so einem immer wurschteliger und kaum zu durchblickenden Verhau entwickelt und das Gottgleiche Gehabe im Forum solche Ausmaße annehmen könnte; zumindest Letzteres scheint mir hier vollkommen anders zu sein, was mich hoffen lässt.Letztlich war/bin ich auf der Suche nach einem System wie ioB, welches per (W)LAN(PoE) eingebundene MultiTransceiver ala BUZZER, welche dann jeweils Transceiver der verwendeten/gewünschten Protokolle aufgesteckt haben (in meinem Fall HM(IP), MAX, IT, ZigBee) nativ über das Netzwerk ansprechen kann (like IP/Portx) und bestenfalls auch noch über die Empfangsfeldstärken ein Diversity hinbekommt. Denn bei mir stehen die Server incl. dem (aktuellen FHEM-Server) auf Grund des WAF im 19" Schrank im Keller und die beiden RPi's mit den je drei SCC hängen ganz unauffällig an zwei Punkten im Haus unter der Decke (habe sogar die Antennen weiß lackiert resp. fertig in weiß gekauft...).
Ich bin gerne bereit, in dieser Richtung meinen Teil beizutragen mit dem, was ich kann (Hardware und Layout (Altium, KiCad), falls das mal, wenn überhaupt, als ioB- eigene Hardware-Modul-Entwicklung in Frage kommt; bei Software bin ich aber raus.
-
... ja, solche Dinge laufen. Aber da ich derzeit zwei RPi mit jeweils drei SCC und einen HMLAN am Laufen habe, würde das bedeuten, das ich mindestens 4 weitere RPi's bräuchte (derzeit faktisch nicht zu bekommen), um zumindest die jetzige Funkabdeckung mit ioB wieder herstellen zu können. Dann hätte ich hier alleine dafür 6 RPi's am Laufen... Unakzeptabel... Und wie ich das dann mit meiner Ölbrenner-Steuerung mache, ist mir im Moment noch so gar nicht klar (den Ölbrenner und die Pumpen macht derzeit ein autarker RPi mit FHEM, welcher über MQTT angebunden ist und so seine Umwelt- und Bedarfsdaten erhält).
Im Grunde ist es sehr schade, das solche Teile wie der BUZZER oder ähnlich modular aufgebaute Multi-Transceiver- Systeme kaum existieren und wenn, nativ von ioB nicht unterstützt werden. Das wäre letztlich die Lösung all meiner Probleme und da würde ich tatsächlich auch Geld in die Hand nehmen. Es wundert mich sogar, das die ioB- Macher/Ihr solcherlei noch gar nicht ins Auge gefasst habt...
Ich hatte es seinerzeit mit Absicht darauf angelegt, nicht für jedes Protokoll jeweils ein eigenes, protokollspezifisches GateWay (CCU, MaxCube, trallalla) zu benötigen. Das macht in meinen Augen keinen Sinn, wenn man sowieso schon eine Software einsetzen kann, welche entsprechende Transceiver nativ unterstützt. FHEM konnte/kann das. Was ich allerdings vor fast 10 Jahren nicht erwartet hatte ist, das sich FHEM zu so einem immer wurschteliger und kaum zu durchblickenden Verhau entwickelt und das Gottgleiche Gehabe im Forum solche Ausmaße annehmen könnte; zumindest Letzteres scheint mir hier vollkommen anders zu sein, was mich hoffen lässt.Letztlich war/bin ich auf der Suche nach einem System wie ioB, welches per (W)LAN(PoE) eingebundene MultiTransceiver ala BUZZER, welche dann jeweils Transceiver der verwendeten/gewünschten Protokolle aufgesteckt haben (in meinem Fall HM(IP), MAX, IT, ZigBee) nativ über das Netzwerk ansprechen kann (like IP/Portx) und bestenfalls auch noch über die Empfangsfeldstärken ein Diversity hinbekommt. Denn bei mir stehen die Server incl. dem (aktuellen FHEM-Server) auf Grund des WAF im 19" Schrank im Keller und die beiden RPi's mit den je drei SCC hängen ganz unauffällig an zwei Punkten im Haus unter der Decke (habe sogar die Antennen weiß lackiert resp. fertig in weiß gekauft...).
Ich bin gerne bereit, in dieser Richtung meinen Teil beizutragen mit dem, was ich kann (Hardware und Layout (Altium, KiCad), falls das mal, wenn überhaupt, als ioB- eigene Hardware-Modul-Entwicklung in Frage kommt; bei Software bin ich aber raus.
@m-i-b-0 sagte in Vorstellung und Starthilfe- Ersuchen:
als ioB- eigene Hardware-Modul-Entwicklung
ioBroker ist eine reine Softwarelösung.
-
@m-i-b-0 sagte in Vorstellung und Starthilfe- Ersuchen:
als ioB- eigene Hardware-Modul-Entwicklung
ioBroker ist eine reine Softwarelösung.
-
... ja, solche Dinge laufen. Aber da ich derzeit zwei RPi mit jeweils drei SCC und einen HMLAN am Laufen habe, würde das bedeuten, das ich mindestens 4 weitere RPi's bräuchte (derzeit faktisch nicht zu bekommen), um zumindest die jetzige Funkabdeckung mit ioB wieder herstellen zu können. Dann hätte ich hier alleine dafür 6 RPi's am Laufen... Unakzeptabel... Und wie ich das dann mit meiner Ölbrenner-Steuerung mache, ist mir im Moment noch so gar nicht klar (den Ölbrenner und die Pumpen macht derzeit ein autarker RPi mit FHEM, welcher über MQTT angebunden ist und so seine Umwelt- und Bedarfsdaten erhält).
Im Grunde ist es sehr schade, das solche Teile wie der BUZZER oder ähnlich modular aufgebaute Multi-Transceiver- Systeme kaum existieren und wenn, nativ von ioB nicht unterstützt werden. Das wäre letztlich die Lösung all meiner Probleme und da würde ich tatsächlich auch Geld in die Hand nehmen. Es wundert mich sogar, das die ioB- Macher/Ihr solcherlei noch gar nicht ins Auge gefasst habt...
Ich hatte es seinerzeit mit Absicht darauf angelegt, nicht für jedes Protokoll jeweils ein eigenes, protokollspezifisches GateWay (CCU, MaxCube, trallalla) zu benötigen. Das macht in meinen Augen keinen Sinn, wenn man sowieso schon eine Software einsetzen kann, welche entsprechende Transceiver nativ unterstützt. FHEM konnte/kann das. Was ich allerdings vor fast 10 Jahren nicht erwartet hatte ist, das sich FHEM zu so einem immer wurschteliger und kaum zu durchblickenden Verhau entwickelt und das Gottgleiche Gehabe im Forum solche Ausmaße annehmen könnte; zumindest Letzteres scheint mir hier vollkommen anders zu sein, was mich hoffen lässt.Letztlich war/bin ich auf der Suche nach einem System wie ioB, welches per (W)LAN(PoE) eingebundene MultiTransceiver ala BUZZER, welche dann jeweils Transceiver der verwendeten/gewünschten Protokolle aufgesteckt haben (in meinem Fall HM(IP), MAX, IT, ZigBee) nativ über das Netzwerk ansprechen kann (like IP/Portx) und bestenfalls auch noch über die Empfangsfeldstärken ein Diversity hinbekommt. Denn bei mir stehen die Server incl. dem (aktuellen FHEM-Server) auf Grund des WAF im 19" Schrank im Keller und die beiden RPi's mit den je drei SCC hängen ganz unauffällig an zwei Punkten im Haus unter der Decke (habe sogar die Antennen weiß lackiert resp. fertig in weiß gekauft...).
Ich bin gerne bereit, in dieser Richtung meinen Teil beizutragen mit dem, was ich kann (Hardware und Layout (Altium, KiCad), falls das mal, wenn überhaupt, als ioB- eigene Hardware-Modul-Entwicklung in Frage kommt; bei Software bin ich aber raus.
-
@m-i-b-0 sagte: RPi's mit den je drei SCC
Wie funktioniert das? Der RPi hat nur eine GPIO-UART.
@paul53 sagte in Vorstellung und Starthilfe- Ersuchen:
@m-i-b-0 sagte: RPi's mit den je drei SCC
Wie funktioniert das? Der RPi hat nur eine GPIO-UART.
die sind stapelbar.
ob die dann verschiedene Adressen haben weiß ich nicht.so in der Art

-
@paul53 sagte in Vorstellung und Starthilfe- Ersuchen:
@m-i-b-0 sagte: RPi's mit den je drei SCC
Wie funktioniert das? Der RPi hat nur eine GPIO-UART.
die sind stapelbar.
ob die dann verschiedene Adressen haben weiß ich nicht.so in der Art

@homoran
Nein, die haben die gleiche Adresse und nutzen nur zwei GPIO's. Die Daten (seriell) werden von einem zum anderen durchgereicht und nur der angesprochene (nach Protokoll) nimmt die Daten entgegen, die anderen ignorieren sie. Umgekehrt liefern alle ihre Daten in Slots ab, je nachdem, wer gerade was zu sagen hat...
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden