Habe gerne geholfen. Das Problem hätte jeder bekommen der einen neuen Homepiloten eingesetzt hätte ohne ein Backup einzuspielen.
Ich habe jetzt auch das Problem mit den „nicht gespeicherte Änderungen“ in der Version 3.03 mit Hilfe von paresy behoben.
Hallo, wird eigentlich der Mehrfach-Wandtaster auch unterstützt?
Habe diesbezüglich hier nichts finden können, habe es einfach mal versucht und wird erkannt.
Allerdings ist dann im Modul nur ein Schalter vorhanden…?
Welchen betrifft dieser Schalter? Müssten doch dann eigentlich drei vorhanden sein…
Gruß Yansop
Hallo Yansp,
Einen Mehfach Wandtaster kenne ich nicht.
Ich habe einen 2 Fach Unterputz Aktor. Der wird über den Homepiloten als 2 Geräte gemeldet.
Ich habe in der neuen Version des Moduls eine Debug Option vorgesehen. Wenn du mir den Output schickst kann ich mir das mal ansehen.
Lg
Hab mir das Ding gerade mal angesehen. Der Wandtaster verhält sich ähnlich einer Fernbedienung an die mehrere Geräte angelernt werden können.
Das heißt es gibt keinen Schalterzustand der via Symcon ausgelesen werden könnte. Ich frage mich also was dein Homepilot über Symcon für den Wandtaster darstellt …
Hallo, ich versuche mal die Darstellung im Vergleich zum HomePilot mit dem Mehrfachwandtaster darzustellen:
Nach dem Anlernen des Mehrfachwandtasters wurden im HomePilot ein Gerät und ein Sensor gefunden.
Der Schalter für das Gerät (An/Aus) schaltet den internen Aktor, hier kann umgeschaltet werden, ob der interne Aktor ein angeschlossenes Gerät schalten soll oder nicht, Wenn nicht kann der unbenutzte Schalter für Funk verwendet werden.
Diesen Schalter habe ich nun auch in der WebFront: Interner Aktor Ein oder Aus.
Aber der zusätzliche Sensor (Sender) wie im HomePilot vermisse ich in der WebFront (s. Anhang).
Im HomePilot kann unter den Sensoreinstellungen die Tastengruppe ausgewählt werden (Aus, 1, 2, 3 oder alle Tastengruppen).
Hallo Bruno,
kann ich dir irgendwie behilflich sein um den Sensor für den Mehrfachwandtaster im Modul einzupflegen?
Du müsstest mir nur sagen, was für Informationen du von mir brauchst bzw. wo diese dann zu finden wären!
Zudem ist mir aufgefallen, das bei den Türkontakten das Auslesen des Zustandes vom Schließkontakt (Geöffnet bzw. Geschlossen) im Modul fehlt.
Es ist hier nur die Information für „Aktualisiert“ vorhanden. Wenn ich dir auch hierbei unterstützen kann…?
Viele Grüße, Yansop.
Hallo yansoph,
die Taster werde ich nicht unterstützen können da sie keinen Status haben sondern nur als Impuls Aktionsauslöser fungieren.
Das gilt genauso für die diversen Fernbedienungen die es für DuoFern gibt.
Alles was über den Rademacher Webserver des Homepiloten dargestellt werden kann, kann auch im Webfront dargestellt werden.
Die Fensterkontakte von Rademacher habe ich nicht. Ich nutze da Homematic Komponenten.
Ich kann versuchen die Fensterkontakte zu unterstützen wenn du mir eine passende Debug Ausgabe zuschickst. Dazu musst du bei den Hompilotenparametern die Option Debug aktivieren. Dann werden alle Json Anfragen und Antworten als Meldungen im Log ausgegeben.
Diese Meldungen brauche ich, vorzugsweise in einer Textdatei.
LG
Bruno
Hallo Bruno,
habe zwar die Debug-Option aktiviert, jedoch im Log wird nichts angezeigt, selbst nach erneutem Ab -und Anmelden des Türkontaktes…
Eine Fehlermeldung konnte ich feststellen, wenn ich die Instanz vom Türkontakt öffne und auf [Status neu einlesen] klicke…
Diesen Fehler erhalte ich aber auch, wenn die Debug-Option ausgeschaltet ist.
Hilft dir das weiter?
Ansonsten bitte melden, Gruß Yansop.
Hallo yansoph,
da wo man die IP Adresse des Homepiloten einstellt gibt es einen Debug Schalter.
Wenn man diese Debugoption aktiviert werde zusätzlich Debug Meldungen im normalen Symcon Meldungslog angezeigt.
Das ist nicht die standard Symcon Debug Option von Symcon die du aktiviert hast.
LG
Habe den Debug Mechanismus in Version 3.04 jetzt so umgestellt, das er mit dem Debug Fenster der Instanz arbeitet.
Hallo,
FYI: nach dem Update des Moduls sehe ich folgende Fehlermeldungen (IPS 5.4):
16.08.2020, 12:21:48 | PHPLibrary | Parameter key in der Funktion HP_GetValue hat keinen Datentyp. Definieren Sie entweder ‚bool‘, ‚int‘, ‚float‘ oder ‚string‘
16.08.2020, 12:21:48 | PHPLibrary | Parameter key in der Funktion HPSensor_GetValue hat keinen Datentyp. Definieren Sie entweder ‚bool‘, ‚int‘, ‚float‘ oder ‚string‘
Tommi
Hallo Tommy,
Das sind zwei Warnmeldungen (Nicht Fehlermeldungen), die aufgrund der strengen Typprüfungen bei den Symcon Modulen ausgegeben werden.
Ich sehe derzeit keine einfache Möglichkeit diese Warnmeldungen zu beheben. Das Modul sollte aber wie bisher problemlos laufen. Ich habe die aktuellste IP-Symcon Version und keine Probleme.
Oder hast du irgend ein Problem feststellen können?
Gruß
Bruno
Ich verstehe das schon, habe ja selber Module geschrieben. Problem habe ich deswegen auch keine feststellen können. War auch nur als Hinweis gedacht.
Wobei ich jetzt nicht verstehe, wo das Problem ist, den string Hint für $key in der GetValue Funktion mitzugeben, denn $key=Ident ist immer ein String. Und an anderer Stelle hast Du auch schon Hints gesetzt.
Zeile 861 in HPDevice.php
public function GetValue( string $key) {
HPSensor is ja davon nur abgeleitet, es ist also nur diese 1 Zeile zu ändern
Tommi
Hallo Tommi,
wenn ich diese Zeile ändere bekomme ich folgende Fehlermeldungen, die dazu führen Das Das Modul nicht geladen wird:
27.08.2020, 17:44:21 | HPNode | <br />
<b>Warning</b>: Declaration of HPDevice::GetValue(string $Ident) should be compatible with IPSModule::GetValue($Ident) in <b>C:\ProgramData\Symcon\modules\SymconHP\HPDevice.php</b> on line <b>1326</b><br />
da habe ich lieber die Warnmeldungen.
Hat jemand eine Idee wie ich Das Problem lösen kann?
Ups, Nameskonflikt beim Funktionsnamen
Idee: Gib Deinem GetValue einen eigenen Namen geben zB. HPGetValue, die Du dann ordentlich typisierst und rufst darin das eigentliche GetValue vom IPSModule auf. Schon existierende Scripte müssen dan leider angepasst werden.
@Paresy: Langfristig sollten aber schon alle internen IPS APIs die richtige Syntax bekommen
Tommi
@BrunoM
Wofür ist deine GetValue Funktion?
Weil das auslesen einer Symcon Variable außerhalb des Modules, müssen die Nutzer mit GetValue(Variable ID) machen.
Und als interne Funktion gibt es schon GetValue in der ipsmodule Klasse.
So gesehen kannst du die ganze Funktion entfernen.
Das überschreiben der SetValue Funktion ist eigentlich kein Problem, allerdings ist die zum setzen vom Instanz-Variablen und nicht, wie bei dir, zum Senden von Werten.
Im Modul benutzt man $this->SetValue um Instanz-Variablen zu setzen, das geht nicht da du den Funktionsnamen zweckentfremdet hast.
Michael
@Nall-chan
GetValue hat doch nichts mit dem setzen von Variablen zu tuen!?
/*
* HP_GetValue($id, $key) bow HPSensor_GetValue
* Liefert einen Deviceparameter (siehe HP_SetValue)
*/
public function GetValue( $Ident ) {
switch ($Ident) {
default:
$value = GetValue(@IPS_GetObjectIDByIdent($Ident, $this->InstanceID));
break;
}
return $value;
}
Ich habe mich hier am Modul von Taxanos orientiert.
HP_GetValue und HPSensor_GetValue greifen auf diese Funktion zurück.
Wenn jemand eine Idee hat wie ich Das kompatibel auflösen kann bin ich für Vorschläge offen.
Ich habe bei GetValue nichts von setzen von Variablen geschrieben.
Wirf die Funktion weg. Es gibt schon in ipsmodule ein GetValue.
https://www.symcon.de/service/dokumentation/entwicklerbereich/sdk-tools/sdk-php/module/getvalue/
Und der User hat GetValue (ID) und nicht HP_GetValue(Instanz ID, ident) und HPSensor_GetValue(Instanz ID, ident) zu benutzen.
Wenn du es von Taxanos alten Hue Modul abgeleitet hast, dann hast du vermutlich nicht darauf geachtet dass das Modul ursprünglich für eine viel ältere Symcon Version war.
Davon abgesehen das auch anderes in dem Modul nicht konform mit den best practice ging und was du mit übernommen hast.
Zum Beispiel bei syncstates sprichst du direkt Ziel-Instanzen mit Instanz-Funktion an um Daten dort einzuschleusen.
Und umgekehrt wird bei HP_SetValue (besser wäre HP_WriteValue) auch direkt HP_Request auf die Bridge Instanz aufgerufen um Kommandos zu senden.
Korrekt wäre es den Datenfluss zu benutzen.
Michael
Hallo nall-chan,
mein Modul wurde ursprünglich auch für eine ältere Symcon Version geschrieben. Auch habe ich ursprünglich nur die HP Version 4 unterstützt.
Du hattest geschrieben:
Das überschreiben der SetValue Funktion ist eigentlich kein Problem, allerdings ist die zum setzen vom Instanz-Variablen und nicht, wie bei dir, zum Senden von Werten.
Im Modul benutzt man $this->SetValue um Instanz-Variablen zu setzen, das geht nicht da du den Funktionsnamen zweckentfremdet hast.
Mein Problem existiert aber nur bei GetValue. Insofern verstehe ich deine obigen Angaben nicht.
Wenn alle Funktionalität so erhalten bleibt kann ich die GetValue Funktion gerne entfernen.
Wenn dem nicht so ist, lasse ich den Treiber so wie er ist mit Warnungen und bisheriger Funktionalität.
Gerne kann sich jemand mein Modul nehmen und nach neuester „best practice“ neu schreiben. Ich bin froh Das jetzt auch die aktuelle HP5 Version unterstützt wird habe aber dazu weder Lust noch Zeit.
Wenn Das neue Modul dann „besser“ ist, werde ich auch gerne wechseln. Das alte HUE Modul von Taxanos läuft bei mi aber besser als das neue, was im App Shop zu haben ist.
Den Hinweis mit SetValue hatte ich aufgenommen, weil es irgendwann Probleme bereiten wird.
So wie jetzt die Warnungen zu den fehlenden Typen.
Es bleibt nicht aus ein Modul an das aktuelle SDK anzupassen.
Sicherlich könnte man in der Doku darauf hinweisen, das es z.b. nur bis Symcon 5.x kompatibel ist.
Michael