Beratung und Grundsatzfragen zum Hardwarekauf

Begonnen von FHEM_ASB, 02 Dezember 2018, 19:12:49

Vorheriges Thema - Nächstes Thema

Guzzi-Charlie

Zitat von: Prof. Dr. Peter Henning am 03 Januar 2019, 07:55:11
Zum Thema Hue: Ich rate auf jeden Fall zu Dresden Elektronik, weil die wohl als Einzige im Stande sind, Änderungen des Status ohne Polling abzufangen und an FHEM weiterzuleiten. Das RPI-RF-MOD blockiert natürlich die Steckleiste => Entweder statt des ZigBee einen ConBee, oder einfach einen billigen zweiten Raspberry Pi. Empfielt sich übrigens auch für RPI-RF-MOD und piVCCU3 (als dritten Raspberry dann).

LG

pah
Hallo,
Ich bin auf der Suche nach Tips und Antworten auf diesen alten Beitrag gestoßen. Ich habe ähnliche Vorstellungen einer Zusammenarbeit von FHEM und Homematic IP auf EINEM RasPi.

Ich habe aktuell ein FHEM-System mit verschiedenen Ankopplungen (Jeelink, One-Wire, MQTT2, etc. am Laufen). Jetzt soll der neue Fußbodenheizungsaktor "https://www.elv.de/homematic-ip-fussbodenheizungsaktor-12-fach-motorisch-hmip-falmot-c12.html" hinzukommen (und NUR der, keine weiteren HM- oder HMIP-Geräte) und diesen möchte ich dann per HMCCU-Modul einbinden. Von Homematic habe ich bisher überhaupt keine Ahnung, deshalb könnte ich ein wenig Unterstützung bei den folgenden Fragen gebrauchen damit ich wenigsten weiß das ich auf dem richtigen Weg bin. Wenn ich das was ich bisher gefunden und gelesen habe richtig verstanden habe dann sollte doch die folgende Konfi funktionieren, oder?

- RasPi 3+ auf dem FHEM und piVCCU3 läuft
- Als Funkgateway zu den HM-Aktoren der USB-Stick "https://www.elv.de/elv-homematic-ip-rf-usb-stick-hmip-rfusb-fuer-alternative-steuerungsplattformen-arr-bausatz.html/bereich/-3"
- Als Verbindung zu FHEM dann das HMCCU-Modul

Ist das so machbar und/oder sind dabei irgendwelche grundsätzlichen Probleme zu erwarten?
- RaspPI 4+: (Cuno V2 -2x KS300, JeeLink -13x EC3000)
- Stromzähler (B+G E-Tech): 6x SDM120M, 9x XTM100A, 38x DRS110M
- LAN: IT LAN-Gateway mit 34x RMF-R1 (Rohrmotor24)
- WLAN: 85x Shelly, 12x Gosund SP111, 16x D1-Mini, 15x Sonoff Basic
- DECT: 6x DECT200, 8x DECT301, - HmIP: 3x FalmotC12, 16x WTH2

Ralph

Moin, auch ich wecke das hier nochmal auf, weil ich nichts passenderes fand.

Zitat von: Guzzi-Charlie am 15 September 2019, 22:15:17
.... Ich habe ähnliche Vorstellungen einer Zusammenarbeit von FHEM und Homematic IP auf EINEM RasPi.

Sowas schwebt mir auch vor.
Grund: Erweiterung / Aufstockung - habe vieles Altes, das gut läuft, aber manches ist nicht mehr greifbar und Neues gibts ja auch.

Habe heute laufend:
FS20, FS20V, HMS, WS_THs, WS_SD; FHTs, SignalDuino 433 mit IT und Flamingos, HM (ohne IP) mit VCCU und Modulplatine, alles mit FHEM auf RasPi 3+

Wunsch ist: HomeMatic IP - Komponenten sollen auch verwaltet und bedient werden, das "alte" muss und soll aber weiterlaufen.

Problem: es gibt wohl viele Wege, wovon ich keinen vollständig verstanden habe, und nun suche ich Rat.

Was muss ich wie mit was umbauen / installieren? Bitte als Kochrezept für Doofe.

Ich denke, das wird über kurz oder lang auf Alle zukommen.
Es gibt ja schon heute Komponenten Homematic (ohne IP) schon nicht mehr.
Von älteren will ich schon gar nicht mehr reden.
Ausflüge in andere Welten wie Shelly sind bei mir schon kläglich gewscheitert.
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

Beta-User

Zitat von: Ralph am 28 Dezember 2020, 19:17:01
Wunsch ist: HomeMatic IP - Komponenten sollen auch verwaltet und bedient werden, das "alte" muss und soll aber weiterlaufen.
[...]
Ich denke, das wird über kurz oder lang auf Alle zukommen.
Zu HM-IP hat Horti dankenswerterweise alles hier zusammengefaßt:
https://forum.fhem.de/index.php/topic,116424.0.html

Ansonsten ist es vermutlich schon so, dass HM-Classic (bis auf den Selberbau-Bereich) mittelfristig tot ist, aber an HM-IP als echte Alternative glaube ich persönlich nicht, und das ZigBee-Zeug ist für Sensorik ziemlich gut und Beleuchtung häufig (fast) alternativlos, wenn man kein WLAN-Gedöns will, aber perfekt ist m.E. weder zigbee2mqtt noch deconz (CC253x-basierte Coordinator sollte man aber wirklich nicht mehr kaufen).

ZitatAusflüge in andere Welten wie Shelly sind bei mir schon kläglich gewscheitert.
Das perfekte System gibt es nicht, und wenn das WLAN-Zeug (mit MQTT2-Modulen oder dem Shelly-Modul) schon in der Einarbeitung zu schwierig ist, bin ich sehr in Zweifel, was dann eine empfehlenswerte Alternative sein soll. M.E. ist derzeit CUL_HM kaum an Komfort zu schlagen (HUEDevice ist ähnlich einfach, aber die dahinterliegende Technik ist es eben nicht in gleichem Maße).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ralph

Uff, bei #17 und #18 habe ich erstmal heftig ein- und ausgeschnauft.

FS20 kann ich nicht abschaffen aus 2 Gründen:
1.) es steckt zuviel Geld drin.
2.) auf FS20V kann ich wegen zahlreicher Batterie-Überwachungen nicht mehr verzichten. Eine Alternative dazu fand ich noch nicht.

Mit MQTT bin ich sowas von heftig auf die Schnauze gefallen, dass ich aus Backups re-installieren musste.

In
Zitat von: Beta-User am 29 Dezember 2020, 13:23:37
Zu HM-IP hat Horti dankenswerterweise alles hier zusammengefaßt:
https://forum.fhem.de/index.php/topic,116424.0.html
werde ich mich einlesen. Liest sich schonmal gut.

Ohne es zu kennen gefällt mir debmatic aus den Empfehlungen schon mal ganz gut.

Die HUE-Lichtorgien brauche ich nicht.

Euch danke ich für die Aufmerksamkeit und die Vorschläge.
Bis neulich ....
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

frank

ZitatIch auch nicht, aber manche Lampen sind alternativlos. Alte Lampe raus, neue Lampe rein, fertig. Kein Zwischenstecker, kein Zwischensockel o.ä.
aber alle vorhandenen lichtschalter werden sinnlos, oder?  ;)
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Sorry @Ralph,

wollte dich nicht erschrecken oder gar angreifen.

Ich hätte beim Einstieg auch nie vermutet, dass ich mal so einen bunten Zoo beieinander haben würde (für Sensorik gibt's auch noch Bluetooth...).

Manches habe ich mir auch nur angetan, um eben solche Fragen halbwegs fundiert beantworten zu können.

Warum es mit MQTT so ein Fiasko war, würde mich interessieren. Weniger, weil ich Werbung für das WLAN-Gedönse machen will, sondern eher, weil mich interessiert, wie man ggf. diese Dinge besser erklären kann. Es ist zugegebenermaßen verwirrend, dass es so viele Module gibt und man zum Einstieg erst mal wissen muss, dass man schlicht einen MQTT2_SERVER mit global definieren muss, damit vieles fast von alleine geht, aber das feedback fast aller "Umsteiger" von MQTT-"alt" zu den MQTT2_.*-Modulen fanden es sehr viel einfacher, und die, die es direkt gemacht haben, waren in der Regel auch schnell produktiv mit ihren Geräten.

Aber auch hier: sowas sollte man erst mal in einer Testinstallation kennenlernen, ein zweiter (ggf. nicht so leistungsfähiger) Pi als Testsystem ist auf alle Fälle eine gute Idee.

@kpwg: Es gibt auch Leuchtmittel für Standardfassungen in ZWave. Die sind nur leider unverhältnismäßig teuer...

Zitat von: frank am 29 Dezember 2020, 17:25:48
aber alle vorhandenen lichtschalter werden sinnlos, oder?  ;)
Na ja, da spielt auch die Gewohnheit stark rein (das Abschalten von Leuchtmitteln macht ZigBee als Mesh aber zugegebenermaßen nicht unbedingt zuverlässiger... Wobei ich die meisten Probleme mit einer Bulb habe, die ziemlich nahe am IO sitzt und "immer on" ist - "Gruscht" vom gelben Möbelhaus halt...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Ralph

Keine Angst, trotz meines Alters werde ich es überleben.
Aber digitale Einläufe verarbeite ich zunehmend langsamer.

ZitatMich hat an FS20 die fehlende Rückmeldung gestört
Mich auch. Aber alle (sich) nicht automatisch / zyklisch meldenden Teile sind schon raus.
Auf FHT(TK)s und TH300 braucht man ja nicht zu verzichten, einer misst bei mir bis -22°C in der TK-T.
An Aktoren habe ich nur noch optisch sichtbare, da kommt die Rückmeldung über die Augen.

Bei MQTT muss ich mich irgendwie verstrickt haben auf Linux-Ebene, plötzlich ging gar nix mehr, ich war in einer Loop.
Keine Ahnung. Wenn ich das gewollt hätte, dann wäre mir das gewiß nicht gelungen.

Ich habe einen 2ten RasPi, der wird gequält.

Seid gewiß, ich werde noch viele Fragen haben ...
FHEM auf RaspberryPi3 mit Geekworm USV und SignalDUINO 433MHz und HM-MOD-RPI-PCB mit 3 HM-Sec-SD-2, 5 FHT, 2 RM 100-2 Uni S, 2 HMS100, 6 CUL_WS, 6 CUL_FHTTK, 11 FS20 und 7 FS20V Spannungsüberwachungen

Wernieman

- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

frank

Zitat von: kpwg am 29 Dezember 2020, 18:52:10
Ich halte eher den Kommentar für sinnlos. Genau das brauchen wir hier...
was soll das jetzt?

wenn ich so eine bulb, mit eingebautem aktor, in meine bestehenden lichtkreise einschraube, verlieren alle vorhandenen schalter dieses lichtkreises ihre funktion.

schlimmer noch. ich muss sogar alle lichtschalter totlegen und umbauen, damit die bulb dauerspannung bekommt.

zusätzlich muss ich für jede schaltstelle neue sender (schalter) besorgen und einbauen.

jetzt fängt das "chaos" an.
vom selben hersteller gibt es in der regel keine sender, bestenfalls fernbedienungen.
wenn ich beta-users threads so verfolge, gibt es viele sender aus fernost, die eventuell nicht vom gateway unterstützt werden.

man braucht also schon mal das "richtige" gateway, scheinbar conbee2, um die grösst mögliche wahrscheinlichkeit zu haben, dass ein sender auch nutzbar wird.
dazu dann noch ordentlich software zum konfigurieren der devices. scheinbar sehr umfangreich, so dass ich sogar wahrscheinlich einen zusätzlichen pi bräuchte.

alles in allem empfinde ich zigbee als grosses experimentierfeld, nach meinen bisherigen recherchen.


da finde ich es eigentlich schon "frech" von dir, zu behaupten, man bräuchte nur die bulb zu wechsen, und fertig.
und das noch zu jemandem, der schon sagt, dass er probleme mit shellys hat.


gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Beta-User

Zitat von: kpwg am 29 Dezember 2020, 18:52:10
Ich halte eher den Kommentar für sinnlos. Genau das brauchen wir hier...
Ich halte den Kommentar ausdrücklich nicht für sinnlos. Man sollte sich nämlich bei ZigBee (und anderen Mesh-Systemen) schon überlegen, wie man es haben will, um bestimmte Probleme zu vermeiden!

Da gibt es tatsächlich eine Fraktion, die das komplette Stilllegen der alten "analogen" Schalter befürwortet (ganz ähnlich wie das bei MiLight der Fall war/ist). Bin noch nicht abschließend zu einem Fazit gelangt, aber bisher habe ich mich dagegen entschieden, Schalter usw. stillzulegen.

Hier mal meine _vorläufige_ Meinung zu den Thesen von frank:
- Schalter werden nicht funktionslos. Alle Bulbs, die ich bisher "irgendwo" gekauft habe, lassen sich "klassisch" einschalten, wenn man die _immer_ klassisch über die Stromzufuhr ein- und ausschaltet. "Seltsam" fühlt es sich nur an, wenn die softwaremäßig aus waren, weil man dann über den "klassischen Schalter" 2x schalten muss, nämlich Stom weg/Strom an, damit sie angehen. Man sollte also entscheiden, ob man bestimmte Ecken mit Schalter oder "anders" bedienen will.
- Bulbs ohne ständige 230V dienen aber nicht mehr als Repeater im Mesh, was das uU. aus dem Tritt bringen kann. Ich kann dazu noch nichts abschließendes sagen, weil der "schaltbare" Teil meiner Bulbs etwas abseits untergebracht ist und z.B. die Sensorik daher sowieso über den "immer on"-Teil des Mesh läuft.
- Ganz ohne Schaltoption (außerhalb des Schaltschranks) mag ich das eigentlich nicht haben, weil ich mind. eine (dauerbestromte) Bulb habe, die sich immer mal wieder "weghängt" und dann "hart" aus- und wieder angeschaltet werden muss. Das ist in dem Fall kein großes Problem, weil da ein Bewegungsmelder mit Schiebeschalter für "off" davor hängt, aber es sorgt immer mal wieder für Irritationen, dass das Ding halt nicht bewegungsmeldergesteuert angeht, wenn es sich weggehängt hat. Vermutlich ist das aber eher ein Defekt an dieser einen Bulb, und ich sollte die schlicht austauschen ::) .

- "Mein Thread" ([unboxing], und vermutlich auch die zu opple und dem Jung) ist/sind nicht unbedingt representativ, weil ich (jeweils) relativ früh halt "irgendwelches Zeug" gekauft habe, um damit rumzuexperimentieren. Grundsätzlich ist ZigBee hochgradig standardisiert, und das meiste (auch unbekanntes Zeug), das sich an die Standards hält, wird auch erkannt. Das ganze mit zigbee2mqtt und deconz jeweils, ohne dass man (abgesehen vom Interface selbst) zusätzliche Hardware bräuchte. Und die verfügbare (und unterstützte) Hardware nimmt stetig zu, so dass man zunehmend auch Geräte für "spezielle Fälle" wählen kann, ohne (!) in eine Falle zu laufen.

- zigbee2mqtt war - als ich es noch genutzt habe - schon ziemlich cool und extrem schnell in der Integration von "allem möglichen", und in Kombination mit MQTT2_SERVER und MQTT2_DEVICE/attrTemplate ist es eigentlich auch sehr "easy" in der Integration in FHEM. Es fehlt eventuell noch ein attrTemplate für HUE-Lichttypen, aber sonst gibt es nichts, was man vermissen würde - sogar Selbst-Bau-Devices (derzeit nur) auf CC2530-Basis sind (mindestens damit (!)) möglich!

- deconz bringt für "ausgereifte" Devices mit phoscon eine sehr anwenderfreuntliche "App" mit und ist mit den HUE.*-Modulen sehr gut in FHEM integriert. Doku für spezielle Fälle könnte man eventuell verbessern, aber ansonsten ist DAS DIE Einsteiger-Lösung schlechthin, vorausgesetzt, man beschränkt sich auf die Hardware, die als "funktionierend" bekannt ist.

"Mankos" von ZigBee (neben dem 230V-Schalter-Thema):
-- Wie die Verknüpfungen zwischen den Geräten laufen, ist manchmal etwas dubios, und für "mache das Licht bei Bewegung nur an, wenn es dunkel ist" braucht man zwingend einen laufenden Server (ist wohl bei allen ZigBee-Lösungen so; das können derzeit nur - neben BidCoS-Geräten - manche (!) ZWave-Geräte (von einem Steinel kann ich das jedenfalls bestätigen) ).
-- 2.4GHz
-- HUEDevice bildet eine Hardware uU. auf mehrere Channel-Devices ab, deren innerer Zusammenhang nicht immer einfach zu erkennen ist (da ist zigbee2mqtt "einfacher").
-- "echte" Schalterprogrammintegration ist ohne Bastelei eher (noch) die Ausnahme. Würde aber wetten, dass irgendwann die Chinesen neben dem europäischen Dosenmaß auch irgendwann die Bedeutung des "55-er"-Maßes erkennen werden.

Ergo ist die verkürzte Schreibweise "Tausche die Bulb, und gut ist...!" eigentlich eine legitime Rückmeldung an jemanden, der mit der früheren (!) MQTT-Implementierung Schwierigkeiten hatte. Jedenfalls würde ich wetten, dass HUEDevice bzw. MQTT2_.* tendenziell einfacher zu verstehen und einzurichten ist wie HMCCU.*, und anders als dort "braucht" man weder einen Pi noch irgendwelche Spezialplatinen, sondern kann das an jeder x64-Hardware per USB-Dongle zum laufen bringen auf dem "einfachen" debian-way!

Aber nochmal auch der deutliche Hinweis: Perfekt ist anders!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MadMax-FHEM

#25
Zitat von: Beta-User am 30 Dezember 2020, 09:44:52
"Mankos" von ZigBee (neben dem 230V-Schalter-Thema):
-- Wie die Verknüpfungen zwischen den Geräten laufen, ist manchmal etwas dubios, und für "mache das Licht bei Bewegung nur an, wenn es dunkel ist" braucht man zwingend einen laufenden Server (ist wohl bei allen ZigBee-Lösungen so; das können derzeit nur - neben BidCoS-Geräten - manche (!) ZWave-Geräte (von einem Steinel kann ich das jedenfalls bestätigen) ).
-- 2.4GHz
-- HUEDevice bildet eine Hardware uU. auf mehrere Channel-Devices ab, deren innerer Zusammenhang nicht immer einfach zu erkennen ist (da ist zigbee2mqtt "einfacher").
-- "echte" Schalterprogrammintegration ist ohne Bastelei eher (noch) die Ausnahme. Würde aber wetten, dass irgendwann die Chinesen neben dem europäischen Dosenmaß auch irgendwann die Bedeutung des "55-er"-Maßes erkennen werden.

Hier kann ich nur zustimmen!
Die Schalterei/Verknüpferei ist mir auch immer noch ein Rätsel (also bei Zigbee / also wann geht es OHNE Bridge [in meinem Fall deCONZ] und wann muss sie laufen / experimetiere da immer noch mit einem Testsystem rum)...

ABER: ich habe mittlerweile eine brauchbare (so hoffe ich: Test steht noch aus) ZigBee-Schalter-Lösung gefunden https://hueblog.com/2020/09/09/not-quite-official-in-wall-switch-with-friends-of-hue-technology/ und es gibt wohl auch (zumindest für mein Schalterprogramm Gira) ähnliches wie bei EnOcen (und mittlerweile wohl auch ZWave) auch für ZigBee, Schalter/Taster die die Energie aus dem "Drücken der Taste nehmen"...

Zuvor hatte ich ja mehrfach (nicht erfolgreich) versucht eine Ikea-Tradfri-FB "umzubauen" (also ohne Batterie und verbunden mit "normalem" Schalter/Taster)...
https://forum.fhem.de/index.php/topic,96578.msg896341.html#msg896341

Weil genau das: fehlende SCHALTER bzw. "Sender" die unter/hinter einen vorhandenen Schalter (oder wenigstens Taster) funktionieren OHNE Batterie ist echt schwer zu finden und hat mich "abgeschreckt" mehr als ein paar "Dekolichter" im Wohnzimmer auf ZigBee "umzurüsten"...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

frank

hi beta-user, danke für die hinweise.

Zitat- Schalter werden nicht funktionslos. Alle Bulbs, die ich bisher "irgendwo" gekauft habe, lassen sich "klassisch" einschalten, wenn man die _immer_ klassisch über die Stromzufuhr ein- und ausschaltet. "Seltsam" fühlt es sich nur an, wenn die softwaremäßig aus waren, weil man dann über den "klassischen Schalter" 2x schalten muss, nämlich Stom weg/Strom an, damit sie angehen. Man sollte also entscheiden, ob man bestimmte Ecken mit Schalter oder "anders" bedienen will.

ok, das ist ja schon etwas besser, als bisher gedacht.

doppeltes einschalten kann für den systembetreiber ja ok sein, aber dritten möchte ich das nicht zumuten wollen.
wenn ein gast nachts aufwacht, muss sichergestellt sein, dass er intuitiv licht einschalten kann.

schlaftrunken in einem fremden zimmer bei rauchmelderalarm aufzuwachen und einen lichtschalter zu finden, kann schon eine herausforderung sein. dann sollte dieser auch "normal" und sicher funktionieren.


allerdings bleibt auch das entscheidende manko, dass eine über den klassischen schalter ausgeschaltete bulb nicht mehr über gateway einschaltbar ist.

automatisierungen sind also glückssache, abhängig von der schalterstellung. genau genommen sind nur automatische on-schaltungen glückssache.


bisher sehe ich die zigbee lichtsysteme bestenfalls als zusätzliche "deko"-beleuchtung.


gruss frank
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Wernieman

Im Grunde sehe ich solche Mischsysteme (Egal welches Produkt) genau deshalb als Problematisch. Man hat 2 Unabhängige Möglichkeiten, es ein/auszuschalten, die sich dann auch gegenseitig beharken. Es sollte nur einen "Kommunikationsweg" gehen. Und das schalten sollte auch unabhängig von einer Zentrale funktionieren.
- Bitte um Input für Output
- When there is a Shell, there is a Way
- Wann war Dein letztes Backup?

Wie man Fragen stellt: https://tty1.net/smart-questions_de.html

Beta-User

Zitat von: frank am 30 Dezember 2020, 12:39:50
doppeltes einschalten kann für den systembetreiber ja ok sein, aber dritten möchte ich das nicht zumuten wollen.
fully agreed!

Sehe zwei Auswege:
Entweder man ersetzt den ursprünglichen Schalter durch einen "immer-on" Taster - da wissen die meisten, dass man den ggf. wieder loslassen muss, kann aber darüber nicht ausschalten (aber man hat "Licht", um den "software"-Taster zu finden).

Oder man packt einen ZigBee-Aktor hinter den Schalter; auch da gibt es zwischenzeitlich Lösungen (sogar "without neutral"). Man muss da nur aufpassen, dass die Schaltleistung passt, aber für Licht reicht es in der Regel...
Dann hat man allerdings entweder ein "dummes" Leuchtmittel oder wieder die Situation, dass zwei hintereinandergeschaltete "smarte" Elemente irgendwie unschön sind. Aber man könnte dann z.B. mit einem zwei-kanaligen Aktor einmal den Schalter abfangen (=> Event für die Bulb-Steuerung) und den 2. Kanal für die Notabschaltung nehmen...
(Das ganze ist aber bei allen Systemen ein Problem und nicht ZigBee-Spezifisch).

Zitat von: Wernieman am 30 Dezember 2020, 12:42:38
Im Grunde sehe ich solche Mischsysteme (Egal welches Produkt) genau deshalb als Problematisch. Man hat 2 Unabhängige Möglichkeiten, es ein/auszuschalten, die sich dann auch gegenseitig beharken. Es sollte nur einen "Kommunikationsweg" gehen. Und das schalten sollte auch unabhängig von einer Zentrale funktionieren.
Auch hier: volle Zustimmung. Deswegen sind die Schalter noch dran und das ganze nur da im Einsatz, wo man sich normalerweise nur aufhält, wenn man halbwegs bei Bewusstsein ist ;) . Außerdem wird eben da gewohnheitsmäßig auch per 230V-Schalter ausgeschaltet...
Emotional hätte ich jetzt kein großes Problem mehr, z.B. an den Stellen, an denen heute ein ZWave-Aktor sitzt, einen in ZigBee einzubauen. HM kam da übrigens nicht in Frage, weil ich dann die ganzen Schalter in Taster hätte wechseln müssen, und in ZigBee gibt es das (bezahlbar) noch nicht so lange. Das mit den Tastern werde ich evtl. aus optischen Gründen noch nachholen, aber das ist ein ganz anderes Thema und hat auch was damit zu tun, dass man dann gleich noch einen Scene-Controller hat...

Klar ist nicht einschaltbar, was "offline" ist, aber immerhin weiß das deconz und FHEM (und bei zigbee2mqtt kann man FHEM wissend machen).

Was Sensorik angeht, ist ZigBee übrigens m.E. kaum zu schlagen. Insbesondere das Xiaomi-Zeug ist günstig, recht genau, batterieschonend und ziemlich zuverlässig, und aus dem Augenwinkel habe ich wahrgenommen, dass es zwischenzeitlich sogar Temp/Hum-Sensoren mit Display  gibt (bisher nur BTLE, die aber ebenfalls m.E. gut zu gebrauchen sind). Dazu vergleichsweise "optisch ok" und v.a. der Bewegungsmelder ist funktional gelungen: guter Erfassungsbereich, superpraktisch, was die Anbringung und Ausrichtung angeht und recht klein. Das einzige, was ich "vermisse", ist diese "sende an peer, wenn dunkel"-Geschichte...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files