[HM-Wired] "Central" Device (aka "virtual" Device)

Begonnen von Thorsten Pferdekaemper, 07 Oktober 2017, 23:04:22

Vorheriges Thema - Nächstes Thema

Thorsten Pferdekaemper

Hi,
ich habe gerade eine HM485-Version eingecheckt, die außer ein paar anderen Verbesserungen ein etwas experimentelles Feature hat: Man kann jetzt ein Device anlegen, das die HmwId des IO-Device hat, also in etwa:

define hmwCentral HM485 00000001

Das Ergebnis ist ein "virtuelles" Device, welches 50 "virtuelle" Tasten hat. D.h. es erscheint in FHEM ein Device, das wie ein HM485-Device mit 50 Taster-Eingängen aussieht, obwohl es kein solches "physisches" Gerät gibt. Man kann aber trotzdem jede der 50 Tasten mit (beliebig vielen) Aktorkanälen peeren. Es steht dabei die komplette Peering-Konfiguration zur Verfügung.
D.h. man kann dann die Aktoren über "set hmwCentral<Kanal> press_short/long" steuern, wobei die Peering-Konfiguration beachtet wird. Außerdem ist dann ein "Toggle" immer ein echtes Toggle und kein von FHEM ausgerechnetes.

Aaaaaber: Ich habe das ganze noch nicht komplett durchgetestet und ich bin mir auch an ein paar Stellen noch nicht ganz sicher, ob das so ganz richtig bzw. gut ist. Es kann also passieren, dass sich noch ein paar Dinge ändern.
Ich überlege mir momentan z.B., ob das Anlegen über obigen define-Befehl so geschickt ist. Falls jemandem was schöneres einfällt, dann bitte sagen.
Wenn jemand diese 50 virtuellen Tasten verwendet, dann bitte hier posten und auch sagen, wie die Verwendung aussieht. Dann werde ich das beim weiteren Vorgehen beachten.

Es wäre nett, wenn jemand das ganze mal ausprobieren könnte. Jegliche Rückmeldungen, Kommentare und Fragen sind willkommen!

Gruß,
    Thorsten




FUIP

habl

Moin Thorsten,

ich habe es ausprobiert, funktioniert bei mir aber nicht so richtig!?

Beim ersten define des virtuellen Devices sieht alles gut aus, hatte allerdings ein 4 Sekunden lahmgelegtes fhem beim anlegen der 50 virtuellen Taster. Ich fände es besser, wenn der User entscheiden kann, wie viele Taster er benötigt.

Dann habe ich einen virtuellen Taster mit einem HMW 12/7 gepeert. Hier ist dann allerdings (von dem virtuellen Taster aus gesehen) kein peering vorhanden. Vom Aktor aus gesehen gibt es ein peering, ein set hmwCentral_01 press_short schaltet auch. Aber ein Konfigurieren des Peering wird mit der Fehlermeldung Unknown argument peeringdetails, choose one of config press_long:noArg press_short:noArgquittiert.

Ein "set hmwCentral getConfig" resultiert in ein RESPONSE TIMEOUT und es wird ab dann weiterhin alle 5 Sekunden versucht den Config auszulesen -->  reading ConfigStatus = READING / FAILED.


Des Weiteren gibt es beim unpeeren noch eine Fehlermeldung im Log:
2017.10.08 15:03:06 1: PERL WARNING: Use of uninitialized value in multiplication (*) at FHEM/lib/HM485/PeeringManager.pm line 519.
2017.10.08 15:03:06 1: stacktrace:
2017.10.08 15:03:06 1:     main::__ANON__                      called by FHEM/lib/HM485/PeeringManager.pm (519)
2017.10.08 15:03:06 1:     HM485::PeeringManager::convertPeeringsToEepromData called by FHEM/lib/HM485/PeeringManager.pm (660)
2017.10.08 15:03:06 1:     HM485::PeeringManager::sendUnpeer   called by ./FHEM/10_HM485.pm (1379)
2017.10.08 15:03:06 1:     main::HM485_SetUnpeer               called by ./FHEM/10_HM485.pm (616)
2017.10.08 15:03:06 1:     main::HM485_Set                     called by fhem.pl (3443)
2017.10.08 15:03:06 1:     main::CallFn                        called by fhem.pl (1745)
2017.10.08 15:03:06 1:     main::DoSet                         called by fhem.pl (1778)
2017.10.08 15:03:06 1:     main::CommandSet                    called by fhem.pl (1174)
2017.10.08 15:03:06 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2502)
2017.10.08 15:03:06 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (906)
2017.10.08 15:03:06 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (549)
2017.10.08 15:03:06 1:     main::FW_Read                       called by fhem.pl (3448)
2017.10.08 15:03:06 1:     main::CallFn                        called by fhem.pl (692)
2017.10.08 15:03:06 1: PERL WARNING: Use of uninitialized value in addition (+) at FHEM/lib/HM485/PeeringManager.pm line 519.
2017.10.08 15:03:06 1: stacktrace:
2017.10.08 15:03:06 1:     main::__ANON__                      called by FHEM/lib/HM485/PeeringManager.pm (519)
2017.10.08 15:03:06 1:     HM485::PeeringManager::convertPeeringsToEepromData called by FHEM/lib/HM485/PeeringManager.pm (660)
2017.10.08 15:03:06 1:     HM485::PeeringManager::sendUnpeer   called by ./FHEM/10_HM485.pm (1379)
2017.10.08 15:03:06 1:     main::HM485_SetUnpeer               called by ./FHEM/10_HM485.pm (616)
2017.10.08 15:03:06 1:     main::HM485_Set                     called by fhem.pl (3443)
2017.10.08 15:03:06 1:     main::CallFn                        called by fhem.pl (1745)
2017.10.08 15:03:06 1:     main::DoSet                         called by fhem.pl (1778)
2017.10.08 15:03:06 1:     main::CommandSet                    called by fhem.pl (1174)
2017.10.08 15:03:06 1:     main::AnalyzeCommand                called by ./FHEM/01_FHEMWEB.pm (2502)
2017.10.08 15:03:06 1:     main::FW_fC                         called by ./FHEM/01_FHEMWEB.pm (906)
2017.10.08 15:03:06 1:     main::FW_answerCall                 called by ./FHEM/01_FHEMWEB.pm (549)
2017.10.08 15:03:06 1:     main::FW_Read                       called by fhem.pl (3448)
2017.10.08 15:03:06 1:     main::CallFn                        called by fhem.pl (692)
2017.10.08 15:03:07 3: hmwCentral: RESPONSE TIMEOUT for 00000001
2017.10.08 15:03:08 3: hmwCentral: RESPONSE TIMEOUT for 00000001


Wozu ich die virtuellen Taster einsetzen kann und werde, kann ich leider noch nicht sagen. Ich hoffe aber hier in einer Diskusion evtl. Einsatmöglichkeiten finden zu können  ;)

VG
  habl

Thorsten Pferdekaemper

Hi,
vielen Dank erstmal für die Rückmeldung. Ich werde mir das im Einzelnen ansehen und mich dann wieder melden.
Gruß,
   Thorsten
FUIP

Thorsten Pferdekaemper

Hi,
Zitat von: habl am 08 Oktober 2017, 15:50:28ich habe es ausprobiert, funktioniert bei mir aber nicht so richtig!?
ich konnte gestern Abend im Prinzip alles nachvollziehen und konnte das meiste auch schon korrigieren. Ein bisschen was fehlt allerdings noch.

Zitathatte allerdings ein 4 Sekunden lahmgelegtes fhem beim anlegen der 50 virtuellen Taster.
Ich entwickle das ganze momentan auf einem "alten" (also 1er) RasPi und optimiere so lange, bis es sich mit der lahmen Kiste ok anfühlt. Das ganze kommt allerdings auch darauf an, wie viele Geräte (genau genommen Kanäle) man bereits im System hat und wie viele Peerings diese wiederum haben. Kannst Du mir dazu ein paar Zahlen aus Deinem System liefern?
Falls Du weißt wie das geht, ware auch eine nytprof-Datei sehr nützlich.

ZitatIch fände es besser, wenn der User entscheiden kann, wie viele Taster er benötigt.
Das habe ich mir auch schon überlegt. Momentan geht das über das Standard-XML, welches auch von der CCU benutzt wird. Das hat halt mal 50 virtuelle Taster. Ich denke aber auch, dass es schöner ware, wenn man das wählen könnte. Ich würde aber erstmal gerne die Probleme mit der momentanen Version lösen.
Auch mit 50 Kanälen darf das nicht 4 Sekunden blockieren. Zumindest muss ich das dann asynchron machen.

Zitat
Dann habe ich einen virtuellen Taster mit einem HMW 12/7 gepeert. Hier ist dann allerdings (von dem virtuellen Taster aus gesehen) kein peering vorhanden. Vom Aktor aus gesehen gibt es ein peering, ein set hmwCentral_01 press_short schaltet auch. Aber ein Konfigurieren des Peering wird mit der Fehlermeldung Unknown argument peeringdetails, choose one of config press_long:noArg press_short:noArgquittiert.
Das konnte ich nachvollziehen und es wird in der nächsten Version gelöst sein.

Zitat
Ein "set hmwCentral getConfig" resultiert in ein RESPONSE TIMEOUT und es wird ab dann weiterhin alle 5 Sekunden versucht den Config auszulesen -->  reading ConfigStatus = READING / FAILED.
"getConfig" ist da natürlich nicht ganz so sinnvoll. Der Befehl liest das EEPROM des Geräts aus. Die virtuelle Zentrale hat kein EEPROM, es gibt da also nichts zu lesen. Ich muss nur noch dafür sorgen, dass für die Zentrale diese unsinnigen Befehle ausgeblendet werden.

Zitat
Des Weiteren gibt es beim unpeeren noch eine Fehlermeldung im Log:
Das habe ich auch gefunden und gelöst. Die neue Version kommt demnächst.

Gruß,
    Thorsten

FUIP

habl

Hallo,

bin jetzt in ein Kurzurlaub.
Kann dir nur kurz schreiben, das ich 6 7/12 und ein 14/12 im Einsatz habe. Die Anzahl der peerings kann ich dir erst am Donnerstag verraten oder hast du auf die schnelle ein Befehl parat sie auszulesen?

Bei mir läuft fhem auf ein NUC.

Von einem nytprof habe ich leider noch nichts gehört.

VG
  habl

ManfredC

Moin,

heute Update gemacht und nun:

2017.10.10 22:20:37 1: reload: Error:Modul 10_HM485 deactivated:
Experimental keys on scalar is now forbidden at FHEM/lib/HM485/PeeringManager.pm line 58, <$fh> line 3370.
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3370.
BEGIN failed--compilation aborted at ./FHEM/10_HM485.pm line 34, <$fh> line 3370.

2017.10.10 22:20:37 0: Experimental keys on scalar is now forbidden at FHEM/lib/HM485/PeeringManager.pm line 58, <$fh> line 3370.
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3370.
BEGIN failed--compilation aborted at ./FHEM/10_HM485.pm line 34, <$fh> line 3370.

2017.10.10 22:20:37 1: reload: Error:Modul 10_HM485 deactivated:
Attempt to reload lib/HM485/PeeringManager.pm aborted.
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3382.
BEGIN failed--compilation aborted at ./FHEM/10_HM485.pm line 34, <$fh> line 3382.

2017.10.10 22:20:37 0: Attempt to reload lib/HM485/PeeringManager.pm aborted.
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3382.
BEGIN failed--compilation aborted at ./FHEM/10_HM485.pm line 34, <$fh> line 3382.

2017.10.10 22:20:37 1: reload: Error:Modul 10_HM485 deactivated:
Attempt to reload lib/HM485/PeeringManager.pm aborted.
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3385.

usw...

Thorsten Pferdekaemper

Hi,
das ist in der Tat blöd. Bei mir gibt das nur eine Warnung...
Kannst Du mal in der PeeringManager.pm die Zeile 58 durch das hier ersetzen:

foreach my $peerid (keys %{$peers->{$peertype.'s'}}) {


Die Datei liegt bei einer normalen RasPi-Installation unter /opt/fhem/FHEM/lib/HM485.

Gruß,
  Thorsten
FUIP

ManfredC

Moin,

ist das:
Compilation failed in require at ./FHEM/10_HM485.pm line 34, <$fh> line 3382.

eine Folge davon?

Gruß,
Manfred

ManfredC

Zitat von: Thorsten Pferdekaemper am 10 Oktober 2017, 22:30:01
Hi,
das ist in der Tat blöd. Bei mir gibt das nur eine Warnung...
Kannst Du mal in der PeeringManager.pm die Zeile 58 durch das hier ersetzen:

foreach my $peerid (keys %{$peers->{$peertype.'s'}}) {



funktioniert!

N8,
Manfred

Thorsten Pferdekaemper

Hi,
gerade habe ich das nächste Update eingecheckt. Damit dürften alle oben angesprochene Probleme (außer einem) behoben sein (auch das mit dem "Experimental keys on scalar is now forbidden").
Das nicht behobene Problem ist das Blockieren beim Anlegen der 50 Kanäle. Bei mir (lahmer RasPi 1) sind das derzeit ca. 2 Sekunden. Es liegt hauptsächlich an zwei etwas langsamen API-Aufrufen, die ich aber nicht weiter optimieren will, da ich dann "inoffizielle" Sachen machen müsste, die vielleicht andere Seiteneffekte haben.
Ich denke aber, dass beim "define" das nicht ganz so schlimm ist, da man kaum im laufenden Betrieb ständig HMW-Zentralen anlegt. (Beim Neustart passiert das ganze beim Abarbeiten der fhem.cfg, was ja sowieso blockiert.)
Die Idee, dass man selbst steuern kann, wie viele virtuelle Taster man bekommt, gefällt mir aber auch. Wahrscheinlich werde ich das auch noch irgendwann einbauen.
Gruß,
    Thorsten


FUIP

Thorsten Pferdekaemper

Hi,
das mit dem Blockieren ist jetzt erledigt, siehe auch hier: https://forum.fhem.de/index.php/topic,79496.0.html.
Man sieht nur nach dem Define nicht sofort alle Kanäle, sondern muss nach ein paar Sekunden mal ein Browser-Refresh machen.
Das mit der einstellbaren Anzahl habe ich nicht eingebaut, da es inzwischen kein Problem mehr sein sollte, wenn man 50 Kanäle mehr hat. ...und wem die 50 nicht ausreichen, der kann ein zweites virtuelles Device anlegen.
Gruß,
   Thorsten
FUIP