FHZ vollständig (empfangen&senden) durch CUL/CUN(O) ersetzen

IP-Symcon 4.x/5.x/6.x Skripte, PHP, SQL (Fragen)
#1

Dank der tollen Arbeit von tommi ist es möglich, einiges auf der funkenden Empfangs- bzw. Leseseite von IPS zu vereinfachen.

CUL/CUN(O) kann über den „F“-Befehl ja auch FS20-Daten senden.

Fragen:

… gibt es eine (einfache) Möglichkeit, die bestehenden IPS-FS20-Sendebefehle (also die Ansteuerung von FS20-Empfängern) auf CUL/CUN(O) umzuleiten und somit die FHZ’s vollständig abzulösen?

… oder muß ich jedes Skript mit FS20-Befehlen anpassen und die Hex-Sequenzen für die „F“-Befehle jeweils manuell ermitteln?

… oder habe ich in der Beschreibung von tommi oder hier im Forum etwas überlesen/übersehen?

… oder ist es sinnvoll/einfacher mit CUL/CUN(O) zu empfangen und mit FHZ zu senden?

schone Weihnachten
wünscht bauhaus

#2

rein theoretisch sollte das auch für IPS möglich sein, denn bei fhem wird genau das gemacht, d.h. das Messageformat der FHZ von/zu CUL zu übersetzen. Man könnte das CUL.pm von fhem also als Vorlage nehmen und den Code nach PHP zu übersetzen. Ist jetzt nicht ganz trivial, da es einige der verwendeten Perl-Konstrukte so in PHP nicht gibt. Wenn man die vorhandenen FS20-Instanzen weiterverwenden will, benötigt man dann auch ein natives CUN/CUL-Modul mit den passenden Interfaces. Wenn man das nicht (selber bauen) möchte ist es wohl einfacher, sich ein paar PHP-Scripte zu schreiben, welche ohne Rücksicht auf vorhandene Komponenten die CUN/CUL-Syntax direkt implementieren. FS20 ist einfach, die Hexkonvertierung ist in meinem Lese-Script schon drin. Bei den FHT muss man zusätzlich besonders wegen der Sendebegrenzung aufpassen und queuen.

Tommi

#3

siehe diesen Beitrag.

Gruß, burg

#4

Wenn man ohne Homematic arbeitet, braucht man die CCU nicht. Deshalb trifft der Hinweis auf den CUxD, der ja in der CCU läuft, hier möglicherweise nicht so richtig. Wahrscheinlich wird es aber auch kein CUN/CUL-Modul geben.

Aber wenn Paresy eine Funktion nicht implementieren möchte: Jeder kann sich sein eigenes IPS-Modul bauen. Das SDK ist gratis.:smiley:
Tommi

#5

SDK gratis ist schon gut, aber könnte man damit überhaupt den geforderten Zugriff auf die über CUxD in der CCU eingebundenen FS20-Komponenten auch in IPS darstellen?
Damit habe ich mich bisher noch nicht ansatzweise befasst und da würde ich wohl mangels Kenntnissen auch scheitern.

Gruß, burg

#6

Ich spreche hier primär über das direkte Ansteuern der FS20-Geräte ohne CCU. Die CCU wird dafür nicht benötigt. Also nix CUxD.
Wer möchte, könnte aber sicher auch mit dem SDK selber die CCU mit CUxD auf Port 2003 ansteuern … soweit das Protokoll bekannt ist.
Was heisst, in IPS darstellen? Idealerweise nimmt man die vorhandenen FS20-Instancen und hängt daran ein Event-Script (oder ein CUN als Splitter-Modul genauso wie jetzt die FHZ) rein.
BTW:
In den meisten Fällen braucht man auch kein Modul mehr, da reicht normale PHP-Programmierung oder auch über SOAP mit (fast) jeder beliebigen Sprache.
Kenntnisse in Programmierung kann man sich übrigens aufbauen, wenn man an einer Lösung interessiert ist. Oder man muss warten, bis es irgendein anderer sich die die Zeit nimmt, die man selber nicht investieren wollte. Oder das aktuelle Problem sich erledigt, weil es vielleicht eine CCU2 oder RWE/eq3-Matic oder xyz geben wird und dann niemand mehr nach der alten FS20-Technik kräht.

Tommi

#7

Hallo Tommi, danke für deine Hinweise zur CUL/CUN(O)-Einbindung und Zustimmung zu deinen Ausführungen zur „Selbstprogrammierung“. Ich sehe auch bei mir immer häufiger, das ich automatisierte Konfigurationen durch (PHP)-Programmierung ersetze um die wirklichen Potentiale/Vorteile der Hausautomatisierung zu nutzen.

Ich fange jetzt mit dem CUNO an, meinen „Interface-Dschungel“ (FHZ(en), Silex(e), IPWE1, EM …) aufzuräumen .

Noch zwei Fragen:

  1. Gibt es aus deiner Erfahrung bei der Programmierung der Interface (in PHP) Do’s oder Dont’s um Einschränkungen bei der Nutzung der IPS-PHP-Konstrukte, dem Web-Interface oder der künftigen iPhone-App zu vermeiden?

  2. Ich habe den CUNO mit dem One-Wire-Interface. Hast Du (oder jemand anders im Forum) schon Hinweise/Code-Snippets zur HMS-Emulation? Der Großteil meiner One-Wire-Komponenten sind 1820 - wäre eine weitere Vereinfachung wenn ich die in IPS als HMS sehen würde.

schöne Weihnachten
Otto

#8

Hallo Otto,

es gibt natürlich Unterschiede zwischen PHP und Modulen. PHP ist schnell in der Entwicklung aber es können nur eine begrenzte Anzahl von verschiedenen PHP-Scripten zur gleichen Zeit laufen, die zulässige Ausführungszeit ist begrenzt und es ist ausschliesslich Event-basiert.
Module haben diese Limitierungen nicht, sie laufen in einem eigenen Thread, können permanent aktiv sein, also auch pollen und sie lassen sich über Interface an vorhandene Datenquellen und Datensenken andocken. Der Nachteil hierbei ist der Aufwand für die Erstellung und die Versionsabhängigkeit.

Um sich nichts zu verbauen dürfte man theoretisch nur die gelieferten IPS-Funktionen nutzen. Aber man bewegt sich mM.auf einen relativ sicheren Pfad, wenn man sich eng an das Grundkonzept hält, d.h. Instancen, Eventscripts und Statusvariablen mit Profilen als gemeinsame Schnittstelle zu Webfront und Co. nutzt. Verlässlich kann Dir das aber nur Paresy erklären.

Der Cuno ist zunächst „nur“ ein normaler CUN mit OneWire-Anschluss. Also Stand heute nix mit Homatic. Aber wenn man die CUL-Maillingliste verfolgt kann man erste Erfolge mit Homematic-Komponenten sehen. Eine IPS-Homatic-Emulation sehe ich dagegen noch nicht mal am Horizont.
Tommi

#9

Hallo tommi,

das Folgende habe ich in der CUNO-Doku gefunden:

O<func> OneWire Command-Set
(CUNO only)
…

  • H<func> HMS Emulation Routines for Temp-Sensors (DS18B20 & DS18S20)

[INDENT]-o Toggle HMS-Emulation on/off; Returns: ON / OFF. Based on found RomCodes an HMS Emulation will be done for OW-Temp-Sensors DS18B20 & DS18S20

-t<dec> Set Time-Interval for HMS-emulated Reporting; <dec>: Seconds in decimal: 0-255; default: 120s[/INDENT]

danach sollte der CUNO die 1820 bereits nach HMS „übersetzen“ und in den eingestellten Intervallen senden. Ich könnte mir dann einiges an (unzuverlässigen) Treibern einsparen. Der CUNO läuft und startet dank deinem Skript bisher sehr zuverlässig.

Gruß
Otto

#10

schon klar, ich meinte die Anbindung an IPS-HMS-Instancen.
Aber warum muss es unbedingt HMS sein?. Es geht doch nur um Temperatur-Sensoren. Die könnte man genausogut nach nach WDE1 oder WS2000 übersetzen. Die Ansteuerung der IPS HMS-Instancen ist nicht dokumentiert
Tommi

#11

Hier ist ein Script zum Schalten von FS20-Geräten mit CUN. Implementiert sind Schalter und Dimmer. Das Script ist als EventScript konzipiert, welches auf die Variablenänderung der FS20-Statusvariablen „Status“ und „Intensität“ getriggert werden sollte. Es nutzt die gleichen Instancen wie meine bisherigen CUN-Scripte.
Die FS20-Instance braucht eigentlich keinen Parent, aber um Warnmeldungen beim Webfront zu vermeiden, sollte eine Dummy FHZ-Instance mit deaktivierter FTDI-Instance als Parent zugewiesen werden.

Tommi


<?php
/**
* CUN/CUL FS20Event Script, Add to EventHandler Instance
* V0.1 26.12.2010
*/

//Regvar-Instance
$reg=12344 /*[CUN\Register Variable]*/;
//Status change
if (($IPS_SENDER == "Variable") || ($IPS_SENDER == "WebFront"))
{
	$me=$IPS_VARIABLE;
	$name=IPS_GetName($me);
	switch ($name) {
		case "Status":$val=$IPS_VALUE?"11":"00";break;
		case "Intensität":$val=dimmer($IPS_VALUE);break;
	}
	$fs20=IPS_GetParent($me);
	$fs20name=IPS_GetName($fs20);
	$addr=FS20_GetDeviceAddress($fs20);
	$hc=$addr['HomeCode'];
	$dev=$addr['Address'];
	$sub=$addr['SubAddress'];
	$code1=four2hex($hc);
	$code2=four2hex($dev.$sub);
	$cul='F'.$code1.$code2.$val;
	IPS_LogMessage("FS20CUL","Send ($name)$fs20 ($fs20name) -> $hc::$dev::$sub ($val)=$cul");
	RegVar_SendText($reg,$cul."
");
}
//#############################
/**
* converting ELV IDs into CUL Hex-Ids
* translated from 10_fs20
* @param string $v ELV ID
* @returns string Hex- Value
*/

function four2hex($v){

  $r = 0;
  foreach  (str_split($v) as $x) {
    $r = $r*4+($x-1);
  }
  $out="";
  $len=strlen($v);
  switch ($len) {
   case 4:$out=sprintf("%02X",$r);break;
   case 8:$out=sprintf("%04X",$r);break;
	}
  return $out;
}
function dimmer($v) {
//dim values from webfront are already steps, not percent!
//otherwise use $out=round(16/100*$v))
if (($v<0)|| ($v>100)) {
	$out=0;
}else{
	$out=$v;
}
return sprintf("%02X",$out);
}
?>
#12

Hallo Tommi,

ich habe Dein Skript wie auch auf Deiner Website beschrieben eingebaut - und es funktioniert! (wenigstens ein Teilerfolg…):slight_smile: Danke schon mal dafür!

„Unschön“ sind aber die von Dir schon beschriebenen Fehlermeldungen…
Wenn ich im FS20 Schalter die übergeordnete Instanz auf „none“ setze, gibt es eine Fehlermeldung im Webfront, wenn ich den FHT1300 PC „außer Betrieb“ setze gibt es Fehlermeldungen vom IPS…

Gibt es da nicht noch eine „schönere“ Lösung?:confused:

Joachim

#13

welche Fehlermeldungen kommen denn noch trotz Dummy FHZ und FTDI-Instanz?

#14

Hallo Tommi,

bei den I/O-Instanzen habe ich die FTDI-Einheit „geschlossen“, deswegen ist davor ein Ausrufezeichen. Fehlermeldung „FTDI: module is not beeing used“.

Vor dem FS20 Schalter ist auch ein Ausrufezeichen, habe jetzt aber noch keinen Fehlermeldungstext bekommen, hängt aber wohl zusammen, ebenso ein Ausrufezeichen vor der Splitter Instanz des FHZ1300 PC…

Joachim

#15

Die Fehlermeldung kannte ich noch gar nicht. Das schwarze Ausrufungszeiches ist normal, die Instance ja deaktiviert. Aber es sollte keine Meldung mehr kommen.
Ich glaube, wir müssen mal ein Feature-Request für eine Funktion starten, mit der man die Parent-Prüfung für die FS20-Geräte abschalten kann.
@paresy:hat so etwas Chancen?
Sonst muss ich ein extra Dummy-Modul mit der Implementation der Interfaces der FHZ schreiben, was dann genau nichts macht…:confused: Ich hatte aber die CUN-Anbindung extra als PHP-Script geschrieben, damit ich kein Delphi-Modul schreiben muss, was die geheimen FHZ-Protokolle nachbildet.

#16

Ich habe jetzt mal doch so ein Dummy-Modul geschrieben, was sich gegenüber FS20 und FHT-Instancen wie eine FHZ1x00PC verhält, aber außer ein wenig Debug nichts tut. „Schwarze Ausrufezeichen“ gibt es so nicht mehr. Man kann (muss aber nicht) das Modul zu Analysezwecken auch zwischen FHZ und Device-Instance(n) hängen.
@Jpaeper:das ist eine um mehr Debugging/Logging erweiterte Version gegenüber meiner Vorabversion.

Tommi

fhzdummy.zip (293 KB)

#17

Hallo Tommi,

vielen Dank, ich habe sie gleich gegen die Vorversion ausgetauscht.

Ich bin immer noch am Basteln (derzeit eher am Verzweifeln) wegen der FHT8v-Anbindung…:frowning:
Ist wohl in dieser Firmware-Version mit dem CUNO „sehr schwierig“…:frowning:

Joachim

#18

Hallo Leute,

ich habe nun seit längerer Zeit einen FHT8v Stellantrieb über CUNO laufen.

Es läuft eigentlich ganz gut, eines jedoch wundert mich: In unregelmäßigen Abständen kommt eine Fehlermeldung (geschätzt ca. ein Mal am Tag) „CUNO: module is not beeing used“, sie verschwindet in der Regel innerhalb der nächsten Minuten auch wieder.

Was bedeutet diese Fehlermeldung überhaupt?

Joachim

#19

Wo kommen die Meldungen,im IPS-Script, wo CUNO selbst?
Tommi

#20

Hallo Tommi,

wie das immer so ist: Ich habe mir die ID nicht gemerkt…:rolleyes:

Aber sie kommt m.E. nicht aus dem Skript.

Ich melde mich besser noch mal, wenn der Fehler wieder auftritt. Ich dachte man kann irgendwie schauen, welche Instanz solch eine Fehlermeldung erzeugt…

Joachim