pair nicht mehr möglich mit dem nanoCUL

Begonnen von eisenmann, 24 März 2019, 20:43:23

Vorheriges Thema - Nächstes Thema

Otto123

Hier ist das mit den virtuellen Temperaturen:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat

Keine VCCU machen! Das funktioniert nicht - hab ich gelesen.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 27 März 2019, 13:38:18
Hier ist das mit den virtuellen Temperaturen:
https://wiki.fhem.de/wiki/HM-CC-RT-DN_Funk-Heizk%C3%B6rperthermostat
@Otto123 ([sorry, ist evtl etwas OT gg. dem Ausgangsthema, können wir auch anderswo fortführen]
Nachdem mich das Thema hier neulich auch beschäftigt hat, bin ich mal dazu ins wiki gegangen. Da wird auch ein at genommen, um den Wert jeweils zu aktualisieren, und nicht via notify nur nach einem Update des Temp-Sensors.

Irgendwie ist die Konstruktion m.E. suboptimal, weil dann ein nur scheinbar aktualisierter Wert immer weiter genutzt wird. Fehlt da irgendwo ein watchdog oder übersehe ich was?

(Sorry, ich nutze keine fake-Sensoren und kann daher nur bedingt mitreden...)
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Otto123

Zitat von: Beta-User am 27 März 2019, 15:14:38
(Sorry, ich nutze keine fake-Sensoren und kann daher nur bedingt mitreden...)
Ich nutze das gar nicht. Ich habe bloß in letzer Zeit immer mal was mitgelesen. Und meine: irgendwo stand es geht nicht mit VCCU Kanälen...
Und ich dachte irgendwer hat das im Wiki alles gerade gezogen :)
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Oh, sorry, Mißverständnis:

Das mit VCCU ist soweit - sagen wir - "korrekt" und steht vermutlich auch so im Wiki.

In der anderen Diskussion ging es um ein at, das alle 2 Minuten lt. Wiki den Temperaturwert an den fake-Sensor übergibt. Das macht m.E. - ohne "Umfeldarbeiten", die aber im Wiki nicht erwähnt sind - keinen großen Sinn, weil unabhängig davon, ob der reale Sensor was übertragt, der vorhandene Wert immer wieder neu in den virtuellen Kanal geschoben wird.

Aber wenn du so eine Konstruktion auch nicht nutzt, müssen wir vielleicht den Thread nochmal aufwärmen, in dem das mit der VCCU Thema war (frank dürfte da besser durchblicken).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

Wzut

Zitat von: Otto123 am 27 März 2019, 16:00:21
irgendwo stand es geht nicht mit VCCU Kanälen...
jein ... es geht auch mit einem VCCU Kanal, allerdings nur mit dem Channel 1, daher wird ein neues Device empfohlen damit immer wieder der Kanal 1 zur Verfügung steht ( müsste das gleiche Thema sein wie bei den Rauchmeldern und dem Teamlead)
Ich wollte es nicht glauben und habe es auch mit Kanälen != 1 versucht und bin wie zu erwarten war gescheitert.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Otto123

Mag alles sein, aber der TE plant dann mehrere VCCUs für diese Zwecke an ohne wirklich zu wissen warum.
Nur weil hier ernsthaft steht man soll zu diesem Zweck eine CCU mit zwei Kanälen anlegen.

Also ist meine grundlegende Empfehlung: Dafür keine VCCU sondern separate virtuelle HM Geräte.
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Beta-User

Zitat von: Otto123 am 27 März 2019, 16:36:35
Mag alles sein, aber der TE plant dann mehrere VCCUs für diese Zwecke an ohne wirklich zu wissen warum.
Nur weil hier ernsthaft steht man soll zu diesem Zweck eine CCU mit zwei Kanälen anlegen.

Also ist meine grundlegende Empfehlung: Dafür keine VCCU sondern separate virtuelle HM Geräte.
Meine Güte, was es nicht alles an Halbwissen gibt auf dieser Welt...
Leseempfehlung für den TE, falls er über diesen externen Beitrag gestolpert war: https://wiki.fhem.de/wiki/Dokumentationsstruktur
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors