[wiregate] - √ - eibga.conf verpflichtend machen, GA-Kuerzel in knx_write/read akzeptieren

[Fry]

Auf Stefans Wunsch in einem neuen Thread:

1. knx_read/write sollen überhaupt nur was schreiben, wenn die DPT/DPTSubId korrekt im /etc/wiregate/eibga.conf eingepflegt ist. Andernfalls soll einfach eine Fehlermeldung resultieren.
2. Der Parameter DPT bei knx_write soll komplett entfallen bzw. ignoriert werden.
3. Weiter sollen knx_read/write auch wahlweise statt der GA den GA-Namen (oder -Kurznamen) annehmen.

Das würde mE Fehler vermeiden und viele Plugins weniger kryptisch machen. Obendrein geht das mE sogar, ohne existierende Plugins zu "breaken", denn der dritte Parameter in knx_write würde von Perl einfach ignoriert, und die eibga.conf kann man ja auch nachträglich pflegen.

Die Tatsache, dass das Wiregate aktuell auch auf GAs schreibt, von denen es "nichts weiß" (=kein eibga.conf-Eintrag), finde ich "freaky", um mal dein Wort zu benutzen....

VG
Fry

EDIT: Ist natürlich letztlich alles eine Designentscheidung und damit die des WG-Maintainers (also deine Entscheidung), aber nur zur Diskussion gestellt - ich stelle mir das ungefähr so vor:

--- wiregated.pl.orig   2012-05-15 10:23:09.000000000 +0200
+++ wiregated.pl        2012-05-15 10:31:54.000000000 +0200
@@ -368,7 +368,10 @@
 sub knx_read {
   my $dst = $_[0];
   my $age = $_[1] || 0; # read hot unless defined
-  my $dpt = $_[2];
+#  my $dpt = $_[2];
+  return unless defined $eibgaconf{$dst}{DPTSubId};
+  $dst=$eibgaconf{$dst}{ga} if $dst!~/^[0-9\/]+$/;
+  my $dpt=$eibgaconf{$dst}{DPTSubId};
   my $src=EIBConnection::EIBAddr();
   my $buf=EIBConnection::EIBBuffer();
   my $hexbytes;
@@ -409,7 +412,9 @@
 #     DPT 14 (4 byte float value) = EIS 9
 #     DPT 15 (Entrance access) = EIS 12
 #     DPT 16 (Character string) = EIS 15
+  $dst = $eibgaconf{$dst}{ga} if $dst!~/^[0-9\/]+$/ && defined $eibgaconf{$dst}{ga};
   $dpt = $eibgaconf{$dst}{'DPTSubId'} unless $dpt; # read dpt from eibgaconf if existing
+  return unless defined $eibgaconf{$dst}{DPTSubId};
   given ($dpt) {
           when (/^10/) {
             my %wd=(Mo=>1, Di=>2, Mi=>3, Do=>4, Fr=>5, Sa=>6, So=>7, Mon=>1, Tue=>2, Wed=>3, Thu=>4, Fri=>5, Sat=>6, Sun=>7);

Allerdings fehlt hier noch die Fehlermeldung im Plugin-Log.

VG, Fry

[JNK]

Sorry, aber das sehe ich etwas anders. Solange es nicht sicher funktioniert, dass der DPT beim ETS4-Import stimmt, solange möchte ich das gerne im Plugin überschreiben können.

Ich habe kaum Lust, alle GAs händisch in das WG einzutragen, und der Import aus dem ETS4-Projekt zerwürfelt mir regelmässig DPT, wenn ich die in der ETS nicht sauber an ALLEN Stellen eingetragen habe.

Gruss,

der Jan

[Fry]

Ok, den Einwand kann ich nicht beurteilen, weil ich anders arbeite: ich importiere GAs nicht von der ETS4 zum Wiregate, sondern von einer Excel-Tabelle in ETS4 UND Wiregate parallel. Und dabei sind alle DPTs in der Exceltabelle gepflegt, folglich auch im WG. Daher käme mir das entgegen.

Insofern: good point.

Allerdings ist eine nicht gepflegte eibga.conf eine echte Fehlerquelle mit möglicherweise schwer zu findenden Fehlern...

Fry

[mumpf]

ich importiere GAs nicht von der ETS4 zum Wiregate, sondern von einer Excel-Tabelle in ETS4 UND Wiregate parallel

Hallo Fry,

könntest Du mal ein Beispiel-Excel posten und verraten, wie man den Import in ETS4 und WireGate macht? Ich habe mich schon immer über über den Export aus der ETS4 geärgert und würde gerne alternativen ausprobieren...

Gruß, Waldemar

[Bodo]

könntest Du mal ein Beispiel-Excel posten

Hoi

Ja das wär' cool, da muss ja nicht jeder das Rad neu erfinden.

[Fry]

Hallo zusammen,
wie gewünscht: anbei meine (geringfügig um sicherheitsrelevante Dinge gekürzte) GA-Datei. Die Exportfunktionen funktionieren so:

für ETS4: im Blatt "Gruppenadressen" die Spalten P/Q (grau hinterlegt, Überschrift "Export zur ETS4") ab Zeile 4 (also ohne die Überschriftszeile) komplett markieren, kopieren und in einem neuen Arbeitsblatt "Werte einfügen". Dieses neue Arbeitsblatt als .csv "mit Trennzeichen getrennt" abspeichern; es lässt sich in der ETS in der Gruppenadressen-Übersicht per Rechtsklick "Gruppenadressen importieren" einfügen. Die Namen der Haupt- und Mittelgruppen muss man allerdings händisch einpflegen.

für Wiregate wie immer einfacher: ein Terminal öffnen (ich nehme rxvt und empfehle das auch weiter) und als root einloggen, im Excel-Blatt "Gruppenadressen" die Spalte R ab Zeile 4 (also ohne Überschrift) markieren und kopieren. Jetzt im Terminal eingeben

perl -pe 's/\\n/\n/g' >/etc/wiregate/eibga.conf2

und Return drücken. Jetzt die vorher in Excel kopierten Daten "einfügen" (im rxvt geht das einfach per Mittel-Mausklick) und zum Abschluss (wenn der Text runtergerollt ist) Ctrl-D drücken. /etc/wiregate/eibga.conf2 sollte fertig und korrekt sein, nach Überprüfung

mv /etc/wiregate/eibga.conf2 /etc/wiregate/eibga.conf
/etc/init.d/wiregated restart

und das WG ist mit der neuen Tabelle unterwegs.

Hoffe, ihr findet es genauso nützlich wie ich...

VG, Fry

[makki]

1. knx_read/write sollen überhaupt nur was schreiben, wenn die DPT/DPTSubId korrekt im /etc/wiregate/eibga.conf eingepflegt ist. Andernfalls soll einfach eine Fehlermeldung resultieren.

Ganz klares nein!
Es gibt keinerlei Notwendigkeit für einen Zwang, die EIB/KNX-GA lokal in jedweder Form zu pflegen.. Das sieht im Log schöner aus, Namen sind aber Schall und Rauch, es zählt im KNX nur die GA..
Es gibt da draussen auch genug WG, die vielleicht 1-5 einfache Plugins mit 2-10 GA's haben, ich fände es ziemlich nervig wenn ich die jew. vorher nochmal anlegen müsste..
Es gibt auch "nicht-power-coder", die sich weder mit dem letzten Detail beschäftigen - noch sollen müssen; also für nen simplen 5-Zeiler, wo man einfach das schreibt was man will..

2. Der Parameter DPT bei knx_write soll komplett entfallen bzw. ignoriert werden.

s.o.: no-go, man kann es ja weglassen, dann gibts nen Fehler im Log (bzw. verhandelbar ist, das man am Rückgabewert != Null/0 von knx_write das erkennen kann)

3. Weiter sollen knx_read/write auch wahlweise statt der GA den GA-Namen (oder -Kurznamen) annehmen.

Das sollte sich ohne "Breakage" machen lassen, ich halte es zwar für ziemlich speziell und sehr viel fehlerträchtiger (Namen können & dürfen nämlich doppelt sein und nicht jeder hat dieses Konzept -
lies: ob man den Rest der KNX-Welt davon überzeugen kann, auf kryptische Zeichenketten statt einer klaren Struktur wie z.B. Gewerk/Stockwerk/[Raum|Funktion] wage ich stark zu bezweifeln
Dazu kommt der ganze Heckmeck mit Gülle-Zeichen (Umlaute, Sonderzeichen usw)..
Da versteh ich dich auch nicht ganz, auf der einen Seite mit RE und hashref um sich werfen (positiv gemeint!) aber andererseits ist eine simple Darstellung eines 32bit int in dreistufiger Form ein Problem das man mit fehlerträchtigen Strings überstülpt

Ausserdem werd ich deswegen meine 693 GA's nicht in ETS3,4,HS usw. umbennen, bei dem Kurznamen kommt bei mir 67x "Rolladen" raus, ist halt so

Aber wiegesagt, das mit den Namen kann man machen, kostet nix (bis der erste kommt, der es verwendet und nicht verstanden hat..)
Aber wir haben im KNX-Standard nunmal primär Grippenadressen, keine selbsterfundenen Namensstrukturen..

@JNK: Das "problem" ist, die ETS3/4 kennt keinen DPT, wenn die GA nicht verbunden ist - und genau da liegt auch einer der Gründe, das ist zwar möglich aber nicht zumutbar, jede Pimmelfutz-GA in der ETS richtig zu verdrahten..

Makki

P.S.: Am Rande: wenn dann die DPTId, die DPTSubId will ich eigentlich vermeiden, weil in 90% der Fälle nach dem Import dank ETS eh falsch und zum en/decode spielt die Subid keine Rolle..

[Chris M.]

Einen Config-Datei-Zwang würde ich auch nicht wollen!

Ich schreibe oft auf nicht genutzte GAs um etwas zu testen oder variiere den DPT...

Nicht jedes Plugin ist so sauber, dass man es veröffentlichen würde.

[Fry]

Es gibt keinerlei Notwendigkeit für einen Zwang, .....

....und offenbar lässt sich für diesen Wunsch hier auch keine Mehrheit erwärmen, also schließen wir das Thema.

Das sollte sich ohne "Breakage" machen lassen, ich halte es zwar für ziemlich speziell und sehr viel fehlerträchtiger (Namen können & dürfen nämlich doppelt sein und nicht jeder hat dieses Konzept -
lies: ob man den Rest der KNX-Welt davon überzeugen kann, auf kryptische Zeichenketten statt einer klaren Struktur wie z.B. Gewerk/Stockwerk/[Raum|Funktion] wage ich stark zu bezweifeln
Dazu kommt der ganze Heckmeck mit Gülle-Zeichen (Umlaute, Sonderzeichen usw)..

Naja... also für mich ist der Übergang von "nackten" GAs auf (selbst gewählte) GA-Kurznamen äquivalent dem Übergang von Assembler (ohne Symbole!) auf Hochsprache.

Die GA-Struktur Gewerk/Stockwerk/[Raum|Funktion] lässt sich gar nicht konsequent durchhalten, aus den verschiedensten Gründen, also bin ich da auch anders drauf - bei mir codieren Haupt- und Mittelgruppe die generelle Funktion (z.B. Fensterkontakt auf/zu), und die Untergruppe benennt die konkrete Funktion (welcher Raum, welches Fenster). Kriege ich übrigens auch keineswegs konsequent durchgehalten.

Aber es führen ja viele Wege nach Rom...

In diesem Sinne, dann eben kein eibga.conf-Zwang, der DPT-Parameter bleibt, und ob du Kurznamen für knx_read/write zulässt, bleibt dir überlassen - ich fände es schön aber sicher nicht notwendig.

Viele Grüße, Fry

[makki]

Die GA-Struktur Gewerk/Stockwerk/[Raum|Funktion] lässt sich gar nicht konsequent durchhalten,

Das kostet im Vorfeld ein bisschen Hirnschmalz bzw. wird man (ich zumindest) es mittendrin nochmal ändern, weil man z.B. ein paar Aspekte vergessen hat - aber mal ehrlich, das gilt für die GA-Struktur genauso wie für irgendwelche erdachten Bezeichner:
gut geplant ist halb gewonnen..
Es gibt da im Feld viele verschiedene Ansätze, von denen ich auch ein paar kenne (deswegen wird die Namens-Nummer so in 99% des Bestandes nicht funktionieren)
aber mal an meinem Beispiel, das lässt sich sehr wohl durchhalten (jew. ein Beispiel dabei):

HG:

[0]name = Zentralfunktionen
(Anwesend, Schlafen,))
[1]name = Beleuchtung
(Licht eben, ohne RGB Effektbeleuchtung)
[10]name = Entertainment
(Russound,mpd,vdr,dreambox)
[2]name = Rolladen
[3]name = Heizung
(Inkl. soll/ist)
[4]name = Schaltfunktionen
(Aktoren, Steckdosen)
[5]name = Sensorik
(sonstiges wie Luftfeuchte, Bodenfeuchte, Regenmenge etc.)
[6]name = Lüftung
(dez. Lüfter inkl. deren Sensorik)
[7]name = Sicherheit
(Watchdogs, Windalarm Markise, und eben die selbstbau-KNX-EMA)
[8]name = Stromverbrauch
(Strommessung, Zähler)
[9]name = Taster
(Tasterfunktionen die nicht direkt agieren sondern per Logik umgemapped werden)

MG:
[0]name = KG
[1]name = EG
[2]name = OG
[3]name = DG
[4]name = Garage
[5]name = Aussen
[7]name = Gesamt
(Anwesend etc.)

UG:
0-29= Flur
30-59=Wohnzimmer
usw.. immer ausgehend von Flur im Uhrzeigersinn und im Raum genauso; also ich könnte ziemlich sicher aus dem Kopf sagen wie die Dimmwert-Status-Adresse des DALI EVG's im WZ links hinten ist ohne diese in 4J einmal benutzt zu haben..
(also so würde ich es heute machen, ich habs historisch ein bisschen verquerer in den GAs aber trotzdem konsistent)

Eine Ausnahme bilden aber z.B. die Zonenfunktionen der Russsound (>200 GA's, zuwas eintippen), gefühlte 600 DMX Channels und gut 40 GA's von RGB-LED's an DALI = HG11 - zuwas sollte ich mir da Namen und Adressen aufschreiben, das ist eine 1:1 Beziehung ohne externe Einflüsse die geht oder nicht..

Wer mehr als 5 Stockwerke, 16 Gewerke oder 8 Räume/Stockwerk hat muss sich halt was anderes ausdenken

Naja... also für mich ist der Übergang von "nackten" GAs auf (selbst gewählte) GA-Kurznamen äquivalent dem Übergang von Assembler (ohne Symbole!) auf Hochsprache.

Tja, so gibt es eben unterschiedliche Sichtweisen, einen uint32 durch einen String zu ersetzen ist für mich (ausser in der finalen Darstellung vielleicht) eher nix.
Aktuelles, ganz abstraktes Beispiel: mein Thunderbird kachelt seit einer Woche nach 3s ab - erstmal nur blöd aber jetzt kommen wir zur Ursache:
weil ich irgendwas in dem sch* nvidia-glx(OpenGL)-Grafiktreiber verfrickelt habe. sigh!! Ich wollte das Ding weder noch brauche ich es, 3D-Gimmicks machen es langsam und stromhungrig, ich will nur meine eMails via IMAP abrufen, dafür brauche ich weder eine Graka mit 512MB noch 2D oder 3D-Beschleunigung - es geht aber nicht mehr weil irgendein vollpfosten es wichtiger findet, die 3D-Engine anzuwerfen als die sch* eMail in Plaintext anzuzeigen ohne abzukacheln

Aber es führen ja viele Wege nach Rom...

So ist es
Und das soll auch jeder so machen dürfen/können wie er nun lustig ist..


Um es möglichst wenig intrusiv zu halten würde ich in knxread/write schauen wenn die GA ($dst) nicht /^[0-9]/ ist in {short} und dann in {name} ?

Makki

[Fry]

Hi makki,
danke für die Ideen bzgl. GA-Struktur. Dazu hab ich noch eine Frage: Wie/wo codierst du die Funktion, also z.B. Dimmwert einstellen vs. Dimmwert auslesen. Da habe ich momentan verschiedene Mittelgruppen.

Um es möglichst wenig intrusiv zu halten würde ich in knxread/write schauen wenn die GA ($dst) nicht /^[0-9]/ ist in {short} und dann in {name} ?

Das fände ich perfekt.

Übrigens, Datenstrukturen in $plugin_info gehen doch nicht (liegt wohl an der Datenbankanbindung). Er speichert dann sowas wie "HASH(0x32432)" als STRING, nicht den Hash selbst.

Ist aber nicht schlimm, es gibt ja Lösungen...

VG, Fry

[Fry]

Aber wir haben im KNX-Standard nunmal primär Grippenadressen, keine selbsterfundenen Namensstrukturen..

Netter Versprecher :-) entspricht ungefähr dem, was ich empfinde, wenn ich diese kryptischen Zahlen in Plugins sehe. Denn "TA_WF" für Außentemperatur Windfang kann ich (als Nicht-Zahlen-Mensch) mir einfach leichter merken als 3/5/12.

Aber das gute ist ja, Perl ("the duct tape of the Internet" laut Larry Wall) lässt uns allen viel Platz zur Entfaltung.

VG, Fry

[makki]

Wie/wo codierst du die Funktion, also z.B. Dimmwert einstellen vs. Dimmwert auslesen.

Hier konkret: in 5er-Gruppen:
30=Schalten - EVG1 - Raum2 (im Stockwerk)
31=Dimmwert EVG1 " "
32=rel. Dimmen 4bit ..
33=Schaltstatus
34=Dimmwert-status

35=Schalten EVG2 - Raum2
usw.

So oder so ähnlich, bei mehr als 6 EVG's / Dimmern pro Raum muss man sich wiederum was anderes ausdenken

Übrigens, Datenstrukturen in $plugin_info gehen doch nicht

So nicht und bringt uns auch (hier) nichts, um lokale Datenstrukturen zu sparen aber es geht (ich leg das die Tage mal ins SVN, just zur Referenz, ich hasse es wenn ich etwas 2x rausfinden muss nur weil ichs nicht mehr finde):

# Beispielplugin um komplexe Datenstrukturen in $plugin_info abzulegen
# V0.1

use Storable;

$plugin_info{$plugname."_cycle"} = 86400;

my %localhash = ( 'test' => 'value1', 
		'counter' => $plugin_info{$plugname."_ticks"} );

store \%localhash, $plugin_info{$plugname."_complex"};

return "stored hash in plugin_info";

# zum laden sowas wie:
#use Storable;
#my %loadedhash = %{retrieve $plugin_info{'PluginInfo_StoreComplex.pl_complex'}};
#return $loadedhash{'counter'};

Makki

[Fry]

Ja solche store- und retrieve-Funktionen hab ich (bspw im Logikprozessor) selbst geschrieben (so ähnlich, und natürlich spezialisiert auf den jeweiligen Fall).

Vorschlag: Eine allgemeine store/retrieve-Funktion (wenn sie light on CPU wäre), könnte im wiregated vordefiniert sein, damit man sie nicht im Plugin jedesmal definieren muss.
(macht viel Sinn gemeinsam mit einem "Style Guide" für Plugins)

VG,
Fry

[makki]

Jow, ich denke da auch an einen globalen, nicht-persistenten Hash (eher ein Object, solangs keiner merkt und es krude Syntax erfordert) für die Plugins, um ggfs. die lokalen Strukturen im eval eher zu vermeiden.

Würde aber erst gerne die Ursachen (es sind mehrere..) für die Leaks genauer kennen; ein globaler store/retrieve ist auch denkbar ($plugin_info{$plugname.'_meinhash'} -> my %meinhash)
"light-on-CPU" ist erstmal relativ, wir haben da weit mehr als genug für diese Zwecke (auch auf einem MIPS24k oder ARMv5TE mit 450MHz auf den ich einen Teil der Suppe gerade versuche zu portieren..), das grössere Problem ist indeed der sehr "grosszügige" Umgang von Perl mit dem RAM Das muss in den Griff bekommen werden..

Makki