Diskussion:HM-RC-12 Funkfernbedienung 12 Tasten - Versionsgeschichte

Pfriemler am 21. November 2017 um 15:32 Uhr

2017-11-21T15:32:36Z

← Nächstältere Version		Version vom 21. November 2017, 17:32 Uhr
Zeile 1:		Zeile 1:
			Der Artikel bedarf dringend einer Überarbeitung, viele Dinge sind veraltet und nicht mehr aktuell.
			Siehe dazu meine Diskussion von 2014.
			Ich schlage vor, die gesamte Erzeugung von ACKs auf die inzwischen moderne Fassung mit virtuellen Buttons einer VCCU zu verlegen. Wenn das schon irgendwo im Wiki beschrieben ist, dann dorthin verlinken.
			--[[Benutzer:Pfriemler\|Pfriemler]] ([[Benutzer Diskussion:Pfriemler\|Diskussion]]) 16:32, 21. Nov. 2017 (CET)




	Zur Anleitung zum "Pairen" mit einem virtuellen Aktor ("Pairing an fhem-dummy"):		Zur Anleitung zum "Pairen" mit einem virtuellen Aktor ("Pairing an fhem-dummy"):

Pfriemler am 14. April 2014 um 06:46 Uhr

2014-04-14T06:46:36Z

← Nächstältere Version		Version vom 14. April 2014, 08:46 Uhr
Zeile 19:		Zeile 19:
	Dies erzeugt zunächst Buttons,hier z.B. HMvirtual_Btn1 bis ~y		Dies erzeugt zunächst Buttons,hier z.B. HMvirtual_Btn1 bis ~y

	3. ~~Jetzt klappt~~ das ~~peeren~~ (!) ~~mit~~		5. Nun sollte man den Button noch umbenennen oder dem Gerät einen anderen Typ geben, denn das Peeren eines realen Buttons mit einem virtuellen Button macht wenig Sinn, auch wenn es funktioniert. Das Ändern des Devices oder des Kanals in einen Switch ist jedoch nicht einmal erforderlich. (zumindest funktioniert es bei mir??)
	~~set {buttonchn} peerChan 0~~ HMvirtual_Btn1 ~~single set [remote]~~ # ~~für virt. Kanal 1~~		rename HMvirtual_Btn1 HMvirtual_ACK1 # Bennenung als ACK-Sender

	~~Lässt man~~ remote ~~weg, wird der virtuelle Aktor sofort ein ACK senden, sobald die FB-Taste gedrückt wird~~.		6. Jetzt klappt das peeren (!) mit
			set {buttonchn} peerChan 0 HMvirtual_ACK1 single set [remote] # für virt. Kanal 1

	~~Natürlich kann~~ man ~~den Button vorher noch umbenennen~~. ~~Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich~~. ??		Lässt man remote weg, wird der virtuelle Aktor sofort ein ACK senden, sobald die FB-Taste gedrückt wird. Anderenfalls muss man sich selbst um die Erzeugung einer ACK-Nachricht kümmern.


Zeile 30:		Zeile 31:
	C) Alternative Lösung zur Statusrückmeldung per LED:		C) Alternative Lösung zur Statusrückmeldung per LED:
	Wenn man im virtuellen Aktor per		Wenn man im virtuellen Aktor per
	attr ~~HMvirtual_Btn1~~ peerIDs (dummy-ID) # dummy-ID kann fehlerhaft sein		attr HMvirtual_ACK1 peerIDs (dummy-ID) # dummy-ID kann fehlerhaft sein
	das peering ändert (etwa per notify als Reaktion auf eine Zustandsänderung), sendet FHEM das ACK ins Nirwana und die Fernbedienungs-LED leuchtet rot.		das peering ändert (etwa per notify als Reaktion auf eine Zustandsänderung), sendet FHEM das ACK ins Nirwana und die Fernbedienungs-LED leuchtet rot.
	Mit		Mit
	attr ~~HMvirtual_Btn1~~ peerIDs (buttonchn-ID) # die FHEM-interne ID des Buttonchannels (nicht der Klarname)		attr HMvirtual_ACK1 peerIDs (buttonchn-ID) # die FHEM-interne ID des Buttonchannels (nicht der Klarname)
	wird das beabsichtigte Peering wiederhergestellt und das ACK bewirkt ein grünes Leuchten der LED.		wird das beabsichtigte Peering wiederhergestellt und das ACK bewirkt ein grünes Leuchten der LED.
	So lässt sich bspw. eine Taste z.B. als Zustandsabfrage benutzen und über langen Tastendruck etwa per notify eine Schaltaktion auslösen.		So lässt sich bspw. eine Taste z.B. als Zustandsabfrage benutzen und über langen Tastendruck etwa per notify eine Schaltaktion auslösen.

			Beachte: Diese Manipulation funktioniert nur mit FHEM-internen Dummies, da reale Komponenten das Peering hardwareintern speichern und einsetzen.

Pfriemler am 14. April 2014 um 06:37 Uhr

2014-04-14T06:37:45Z

← Nächstältere Version		Version vom 14. April 2014, 08:37 Uhr
Zeile 2:		Zeile 2:

	A) ich meine, wir sprechen hier inzwischen vom Peeren - ?		A) ich meine, wir sprechen hier inzwischen vom Peeren - ?



	B) Die Befehlsstruktur von FHEM scheint sich mittlerweile an manchen Stellen geändert zu haben:		B) Die Befehlsstruktur von FHEM scheint sich mittlerweile an manchen Stellen geändert zu haben:
Zeile 24:		Zeile 26:
	Natürlich kann man den Button vorher noch umbenennen. Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich. ??		Natürlich kann man den Button vorher noch umbenennen. Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich. ??

	Alternative Lösung zur Statusrückmeldung per LED:

			C) Alternative Lösung zur Statusrückmeldung per LED:
	Wenn man im virtuellen Aktor per		Wenn man im virtuellen Aktor per
	attr HMvirtual_Btn1 peerIDs (dummy-ID) # dummy-ID kann fehlerhaft sein		attr HMvirtual_Btn1 peerIDs (dummy-ID) # dummy-ID kann fehlerhaft sein

Pfriemler am 14. April 2014 um 06:37 Uhr

2014-04-14T06:37:15Z

← Nächstältere Version		Version vom 14. April 2014, 08:37 Uhr
Zeile 24:		Zeile 24:
	Natürlich kann man den Button vorher noch umbenennen. Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich. ??		Natürlich kann man den Button vorher noch umbenennen. Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich. ??

	~~Eine statusabhängige~~ ACK~~/NACK~~-~~Rückmeldung mit anderen Mitteln zu erzeugen ist mir auch noch~~ nicht ~~gelungen, ich arbeite ebenfalls daran~~.		Alternative Lösung zur Statusrückmeldung per LED:
			Wenn man im virtuellen Aktor per
			attr HMvirtual_Btn1 peerIDs (dummy-ID) # dummy-ID kann fehlerhaft sein
			das peering ändert (etwa per notify als Reaktion auf eine Zustandsänderung), sendet FHEM das ACK ins Nirwana und die Fernbedienungs-LED leuchtet rot.
			Mit
			attr HMvirtual_Btn1 peerIDs (buttonchn-ID) # die FHEM-interne ID des Buttonchannels (nicht der Klarname)
			wird das beabsichtigte Peering wiederhergestellt und das ACK bewirkt ein grünes Leuchten der LED.
			So lässt sich bspw. eine Taste z.B. als Zustandsabfrage benutzen und über langen Tastendruck etwa per notify eine Schaltaktion auslösen.

Pfriemler: Teilweise veraltete Befehle für Pairen/Peeren mit FHEM, Gegenvorschläge.

2014-04-02T19:43:31Z

Teilweise veraltete Befehle für Pairen/Peeren mit FHEM, Gegenvorschläge.

Neue Seite

Zur Anleitung zum "Pairen" mit einem virtuellen Aktor ("Pairing an fhem-dummy"):

A) ich meine, wir sprechen hier inzwischen vom Peeren - ?

B) Die Befehlsstruktur von FHEM scheint sich mittlerweile an manchen Stellen geändert zu haben:

1. hmClass ist nicht mehr definiert, Fehlermeldung

2. Das Kommando “devicepair“ gibt es nicht mehr, es wurde durch das gleichsyntaktische „peerChan“ ersetzt

3. Das Pairen mit einem Aktor+Channel in einer Entity klappte hier nicht. Es ist besser, einen virtuellen Kanal anzulegen.

4. Dieser Kanal ist jedoch nicht anlegbar, wenn das virtuelle Device bereits „subType = switch“ ist.
Richtig ist also aus meiner Sicht
define HMvirtual CUL_HM XXXXXX # gültige, freie HM-ID, sechstellige Hex-Zahl, Großbuchstaben
set HMvirtual virtual y # Anzahl benötigter Kanäle, meist reicht ja einer
Dies erzeugt zunächst Buttons,hier z.B. HMvirtual_Btn1 bis ~y

3. Jetzt klappt das peeren (!) mit
set {buttonchn} peerChan 0 HMvirtual_Btn1 single set [remote] # für virt. Kanal 1

Lässt man remote weg, wird der virtuelle Aktor sofort ein ACK senden, sobald die FB-Taste gedrückt wird.

Natürlich kann man den Button vorher noch umbenennen. Das Ändern des Devices oder des Kanals in einen Switch ist nicht einmal erforderlich. ??

Eine statusabhängige ACK/NACK-Rückmeldung mit anderen Mitteln zu erzeugen ist mir auch noch nicht gelungen, ich arbeite ebenfalls daran.