[gelöst] virtuelles Device mit mehreren Kanälen

[Sparkie]

Hallo zusammen,

vergangene Tage habe ich meinen FHEM Server neu aufgesetzt. Nun wollte ich ein virtuelles Device anlegen und mit meiner Homematic Station (LAN) verbinden. Jetzt kann ich aber nur ein virtuelles Gerät erstellen mit meiner HMid. Bei jedem weiteren in der "DEF" muss etwas anderes stehen (FehlerMeldung: "hmid bereits vergeben")

Nun meine Frage:
Kann ich ein virtuelles Device anlegen und mehrere Kanäle erstellen, die alle mit einem anderen "at-Event" Daten an meine anderen HomeMatic-Geräte übermitteln?

Gruß

[CoolTux]

Du nimmst Deine HMID und hängst ein 01 für den ersten virtkanal dann 02 für den 2. virt kanal und so weiter ran.

[Beta-User]

Achtung: Wenn es um virtuelle Temperatursensoren geht, kann das uU. Schwierigkeiten geben, wenn man virtuelle Kanäle nutzt. Aus irgendeinem Grund nehmen die immer Kanal 2.

War neulich erst mal wieder Thema: https://forum.fhem.de/index.php/topic,79857.0.html

Gruß, Beta-User

[Beta-User]

Je Temperatur ein Device, so hatte ich das auch verstanden (scheint bei virtuellen Fensterkontakten ähnlich zu sein).

Wie bereits der zitierte Beitrag nahelegt: Solange es keine ID's sind, die es bereits irgendwo anders in deinem FHEM gibt, ist es m.E. egal.

[Beta-User]

Das ist sehr seltsam und sollte doch gerade nicht so sein .

Kannst du mal list's liefern von den 4 Geräten?

[Hollo]

Pro Sensor jeweils ein virtuelles Device mit jeweils einer eigenen HMID und dann einem virtuellen Kanal.

_Deiner HMID_ bedeutet, dass Du eine nehmen sollst, die bisher noch nicht vergeben ist.

[Beta-User]

Das sieht so aus, also wäre beim peering etwas schief gelaufen.

Dann sollte aber auch der sz-Sensor in der Peer-Liste vom HM_tmp_wz stehen. Wenn das so ist: erst mal ein unpeer durchführen.

[Beta-User]

Sorry, aber Werksresets und neu pairen sind erfahrungsgemäß nicht der Brüller, weil man dann immer wieder von vorne anfängt zu suchen -vor allem, wenn nicht pairSerial genutzt wird. Vermutlich wurde da der virtuelle Kanal befüllt, während der RT auf pairing gewartet hat (ohne altes Pairing mit der Zentrale, das sowas verhindert...)...

Bitte je nach einem sauber abgeschlossenen pairing ein getConfig machen und die list's liefern bzw. dann das unpeer nochmal wiederholen.

[Beta-User]

Bitte je nach einem sauber abgeschlossenen pairing ein getConfig machen und die list's liefern bzw. dann das unpeer nochmal wiederholen.

Ist das pairing sauber durch?!?

[Beta-User]

Der Thermostat ist nur scheinbar gepairt, das erkennt man an dem "d:000000":

Code Auswählen Erweitern

lastMsg    No:F7 - t:10 s:308A99 d:000000 0AA92E0A0040

Und das list zeigt auch deutlich, dass nicht alles sauber abgearbeitet war:   

Code Auswählen Erweitern

protCmdPend 14 CMDs_pending

Bevor das nicht abgearbeitet ist (und dann immer noch eine sinnvolle Zentrale in den Readings steht), macht alles andere keinen Sinn...

Vermutlich hilft hier nur warten (1%-Regel?) oder ein clearAll+pairSerial

[Beta-User]

hab jetzt manuell alle peers gelöscht.

Was bedeutet "manuell gelöscht"?

Und nochmal zur allgemeinen Vorgehensweise: Um die peers brauchst du dich erst dann kümmern, wenn das pairing sauber durch ist und keine cmd's mehr pending sind. (Siehe dazu das wiki zum pairen bei HM).

[Beta-User]

Danke für dir Rückmeldung, dass sich der Nebel zu lichten scheint.

Das WZ-Thermostat war übrigens das mit dem kaputten pairing .

Wenn dann nachher alles so ist, wie es sein soll: Bitte nicht vergessen, den Thread mit [gelöst] zu kennzeichnen.