Komplett überarbeitetes ECMD und ECMDDevice vom 16.3.2014

Tom_S · 13 April 2014, 13:15:27

hallo Boris,

habe alles noch mal getestet. Jetzt funktioniert alles und ich werde es jetzt erst mal so übernehmen.
Mal sehen ob im Betrieb noch was auffällt. Erst mal Danke, sehr schön.

@kpwg
der Vorschlag mit devStateIcon mit on.*:on:off off.*:off:on kam damals. Aber bei über 50 Geräten fand ich das nicht so gut. Jetzt geht es ohne. Kannst ja mal testen.

mfg Tom_S

H_doc · 13 April 2014, 15:54:07

Hallo Boris,

nach Rueckkehr und JetLag habe ich eben die neueVersion aus deinem Posting probiert.
Es kommt jetzt keine Fehlermeldung mehr und es funzt auch einigermaßen.
Die Verbindung ist zwar nicht sehr stabil und ich muss sehr oft den Port resetten, das kann aber auch an der Verbindung/dem Gerät selbst liegen.
Hier muss ich noch einmal genauer auf Fehlersuche gehen.

Gruß

Heiner

Tom_S · 14 April 2014, 13:05:51

hallo Boris,

habe nun doch noch eine Kleinigkeit - ist mir durch die logs aufgefallen

Code Auswählen


params port pin
reading power match "port %port %pin \d\n"
reading power postproc { s/.*port %port %pin (\d)\n.*/$1/s; $_ ? "off" : "on" }

funktioniert. Nur das ich das "power" im STATE nicht los werde. "power on : power off"

Code Auswählen


reading on match "port %port %pin 0\n"
reading off match "port %port %pin 1\n"
reading on postproc { s/.*port %port %pin 0\n.*//s; "$_" eq "" ? "" : "Fehler" }
reading off postproc { s/.*port %port %pin 1\n.*//s; "$_" eq "" ? "" : "Fehler" }

funktioniert auch. Wenn ich hier das attr "event-on-change-reading .*" setze, dann kommen keine Events mehr. Kann mir auch denken warum, on bleib ja on und off bleibt off. Der STATE ändert sich aber. Kannst du da nochmal schauen?

Tom_S

Dr. Boris Neubert · 15 April 2014, 00:49:20

Hallo,

das ist so gewollt. Im state steht READING: VALUE. Wenn Du was anderes willst, mußt Du stateFormat verwenden.

Grüße
Boris

Tom_S · 15 April 2014, 09:02:24

Das dann "power on: power off" steht ist ja oK. War auch nur die Erklärung warum ich Variante zwei probiert habe. Aber ich müsste für die zweite Variante bei "event-on-change-reading .*" ein Event bekommen. Das reading "state" ändert sich doch.

mfg
Tom_S

Tom_S · 15 April 2014, 18:00:22

was mir noch aufgefallen ist:
bei allen ECMDDevices, kommt das attr verbose in der Auswahl auf der Deteilseite zweimal vor.
Vermutlich weil es in 66_ECMD.pm in Zeile 45 mit

Code Auswählen


$hash->{AttrList}= "classdefs verbose:0,1,2,3,4,5 logTraffic:0,1,2,3,4,5 timeout";

definiert wird und dann in 67_ECMDDevice.pm in Zeile 51 erneut. Du fügst es doch mit

Code Auswählen


.....IODev class ".  $readingFnAttributes;

an. Kann das in ECMDDevice raus ? Es verwirrt etwas und ich habe nicht getestet welches, oder ob beide funktionieren.

Tom_S

Dr. Boris Neubert · 15 April 2014, 20:25:01

Zitat von: Tom_S am 15 April 2014, 09:02:24
Aber ich müsste für die zweite Variante bei "event-on-change-reading .*" ein Event bekommen. Das reading "state" ändert sich doch.

Habe Dein Problem verstanden. Aus historischen Gründen (= ich weiß nicht mehr warum ich das so gemacht habe) wird für das state-reading behauptet, changed wäre falsch, damit kein Event getriggert wird. Ich habe das behoben. Du kannst einfach in Zeile 118 in 67_ECMDDevice.pm das ",1" im Argument von ReadingsBulkUpdate löschen. Dann sollte es gehen.

Viele Grüße
Boris

Dr. Boris Neubert · 15 April 2014, 20:29:19

Zitat von: Tom_S am 15 April 2014, 18:00:22
was mir noch aufgefallen ist:
bei allen ECMDDevices, kommt das attr verbose in der Auswahl auf der Deteilseite zweimal vor.
Vermutlich weil es in 66_ECMD.pm in Zeile 45 mit
Code Auswählen Erweitern
$hash->{AttrList}= "classdefs verbose:0,1,2,3,4,5 logTraffic:0,1,2,3,4,5 timeout";
definiert wird und dann in 67_ECMDDevice.pm in Zeile 51 erneut. Du fügst es doch mit
Code Auswählen Erweitern
.....IODev class ". $readingFnAttributes;
an. Kann das in ECMDDevice raus ? Es verwirrt etwas und ich habe nicht getestet welches, oder ob beide funktionieren.

Es ist an mir vorübergegangen, daß verbose standardmäßig bei allen Devices gesetzt wird. Es kann in ECMD und ECMDDevice raus. Ist bei mir lokal schon behoben. Wenn die Version in Kürze freigelassen wird, ist es dann allgemein verfügbar.

Danke für die Beobachtung!

Viele Grüße
Boris

Tom_S · 15 April 2014, 20:47:15

hallo Boris,

Zitat
Du kannst einfach in Zeile 118 in 67_ECMDDevice.pm das ",1" im Argument von ReadingsBulkUpdate löschen.

eine ,0. Habe ich gelöscht und es scheint zu gehen. werde ich beobachten. Ich habe einfach keinen Plot hin bekommen. Im LogFile steht "power: on". Woher wohl der Doppelpunkt kommt ??

Grüße

Tom_S · 15 April 2014, 21:07:28

habe das erste readingsBulkUpdate ( Zeile 114 ) auch mit

Code Auswählen


&& $value ne ""

bei leerem $value auskommentiert. Dann ist auch der Doppelpunkt weg.

Tom_S · 16 April 2014, 09:09:19

hallo Boris,

scheint alles zu laufen. Eine Frage habe ich noch. Ist der Match-String irgendwie begrenzt? Bei mir 52 Zeichen.

Code Auswählen


2014.04.16 08:58:40 3: NETIO91: read "port 0 3 0\n"
2014.04.16 08:58:42 3: NETIO91: read "port 0 3 1\n"
2014.04.16 08:58:52 3: NETIO91: read "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 1\n"
2014.04.16 08:59:52 3: NETIO91: read "port 0 0 0\nport 0 1 1\nport 0 2 1\nport 0 3 1\nport"
2014.04.16 08:59:52 3: NETIO91: read " 2 2 1\n"
2014.04.16 08:59:52 2: autocreate: define ECMDDevice message  2 2 1
2014.04.16 08:59:52 1: ERROR: Unknown module message

kann vorerst mal die Ausgabe in der Firmware begrenzen. Kommt im Monent alles zu zur selben Zeit.

Dr. Boris Neubert · 16 April 2014, 21:19:30

Zitat von: Tom_S am 15 April 2014, 21:07:28
habe das erste readingsBulkUpdate ( Zeile 114 ) auch mit
Code Auswählen Erweitern
&& $value ne ""
bei leerem $value auskommentiert. Dann ist auch der Doppelpunkt weg.

Wird so berücksichtigt werden im Release.

Grüße
Boris

Tom_S · 17 April 2014, 10:45:58

hallo Boris,

stellst du die fertigen Dateien hier nochmal zum testen zur Verfügung bevor sie per Update verteilt werden?
Weist du wo und warum der Matchstring auf 52 Zeichen begrenzt ist?

mfg
Tom_S

kpwg · 18 April 2014, 11:10:01

Zitat von: Tom_S am 13 April 2014, 13:15:27
@kpwg
der Vorschlag mit devStateIcon mit on.*:on:off off.*:off:on kam damals. Aber bei über 50 Geräten fand ich das nicht so gut. Jetzt geht es ohne. Kannst ja mal testen.

Ups, nun verstehe ich Deinen Wunsch!

Mit meinen aktuell 9 benutzten Geräten sieht das anders aus.

Getestet habe ich: leider funktionierte es trotzdem nicht. ich erhalte stets "on OK" bzw. "off OK". Bin aber der Sache auch noch nicht nachgegangen.

kpwg · 18 April 2014, 12:06:36

Habe mich an die Intertechno-Aktoren gewagt. Dabei gibt es seitens Ethersex keine Besonderheiten: es muss nur ein RFM12-433 angeschlossen sein und das Intertechno-Protokoll beim Kompilieren aktiviert sein. Derzeit warte ich noch auf Antenne und Pigtail; dann gibts auch Bilder von der Hardware, mit der ich sende.

Die rfm12_it.classdef sieht dabei so aus:

Code Auswählen

# Uebergabeparameter Intertechno Coding: Familie + Gruppe + Geraet
params it_fam it_group it_dev
# Umsetzung in ECMD Befehle
set on cmd {"rfm12 intertechno %it_fam %it_group %it_dev 1\n"}
set on expect "OK\n"
set on postproc {s/OK\n//; $_;}
set off cmd {"rfm12 intertechno %it_fam %it_group %it_dev 0\n"}
set off expect "OK\n"
set off postproc {s/OK\n//; $_;}

Neu ist das postproc, womit ich per Substitutionsoperator aus dem "OK\n" nichts mache. Damit ist das Reading nun "on" oder "off" und erspart mir "devStateIcon on.*:on:off off.*:off:on". Danke TOM_S für den Denkanstoß! Somit kann ich jetzt ohne Umstände das Symbol mit dem Smartphone toggeln. So schaut das Device nun aus:
(http://abload.de/img/intertechno_wandlampeivj9q.jpg)

Viele Grüße, Ricardo