Hallo zusammen,
ich habe vor ein paar Tagen an dem Ausbau des ECMD und ECMDDevice Modules gearbeitet.
d.h ich habe folgendes angepasst:
ECMD:
* ECMD_Read und ECMD_Ready Funktion ergänzt
* ECMD_ReadAnswer ergänzt um sicher zu stellen das Antworten immer gesamt gelesen und zurückgegeben werden.
d.h. lesen bis ein \n das Kommando beendet/abschließt
* Bug in ECMD_Write behoben.
Es wurde ursprünglich auf der Console ein Fehler ausgegeben sobald das Gerät am USB Port auf den Schreibbefehlt keine Antwort gegeben hat.
* Attribut NoWriteFeedback ergänzt, da beim setzten von Werten/absetzen von Commandos welche keinen Rückgabewert zurück melden es zu unschönen Verzögerungen führt
ECMDDevice:
* ECMDDevice_Parse Funktion ergänzt
Löst die empfangenen Nachrichten in den entsprechenden ECMDDevice Modul Namen wieder zurück auf und triggert damit notifys.
Ich würde gerne die Änderungen für das SVN bereit stellen und hoffe damit auch weiter die Module updaten zu können um ggf. Bugs und Verbesserungen auch mit zu bekommen.
Ist das so möglich?
Zitat von: ulli schrieb am Di, 23 Juli 2013 18:31Hallo zusammen,
ich habe vor ein paar Tagen an dem Ausbau des ECMD und ECMDDevice Modules gearbeitet.
Ich finde es super, daß Du Dir die Mühe gemacht hast, diese ganzen Erweiterungen in das Modul einzubauen. Du hast sie sicher für Dich gut getestet. Ich werde Deine Versionen sehr gerne einchecken, möchte aber zunächst von ein paar mehr Anwendern hören, daß das Modul auch bei ihnen gut läuft. Bei mehr als 100 Installationen ist das eine sinnvolle Vorsichtsmaßnahme.
Ich würde mich also sehr freuen, wenn sich diejenigen, die die Module bereits heruntergeladen haben, in diesem Thread melden, ob sie bei ihnen funktionieren, und wenn ein paar mehr die Module testen wollen, wäre ich auch sehr dankbar.
Abhängig vom Umfang des (positiven) Feedbacks checke ich die Module dann kommendes oder übernächstes Wochenende ein.
Viele Grüße
Boris
ich werde das gerne testen, komme da aber frühestens im Lauf der nächsten Woche dazu.
Zum Testen habe ich das AVR-NetIO mit zwei ADC im Einsatz.
Hallo,
habe die zwei Module ausprobiert.
Mein AVR-Net IO und alle Devives werden nicht mehr erkannt.
ZitatPlease define Relais1 first
Please define PIR first
Please define PIR first
2013.07.24 15:50:05 1: statefile: Please define PIR first
2013.07.24 15:50:05 1: Including ./log/fhem.save
Please define Relais1 first
Relais1 error: unknown class RELAIS.
Please define Relais5 first
Relais5 error: unknown class RELAIS.
Please define Relais4 first
Relais4 error: unknown class RELAIS.
PIR error: unknown class adc.
Please define lichtsensor first
lichtsensor error: unknown class adc.
temp_kessel_out error: unknown class ONEWIRE.
temp_vorlauf_ist error: unknown class ONEWIRE.
temp_aussen error: unknown class ONEWIRE.
temp_keller error: unknown class ONEWIRE.
Please define NETIO first
Please define NETIO first
2013.07.24 15:50:05 1: configfile: NETIO: Error: timeout reading answer for get V
2013.07.24 15:50:05 3: WEB_Sonja: port 8085 opened
2013.07.24 15:50:05 3: WEB_Alex: port 8084 opened
2013.07.24 15:50:05 3: WEB: port 8083 opened
2013.07.24 15:50:03 1: Including ./FHEM/OWDevices.cfg
2013.07.24 15:50:03 1: Including ./FHEM/timer.cfg
2013.07.24 15:50:03 1: Including ./FHEM/watchdog.cfg
2013.07.24 15:50:03 3: Please define Relais1 first
2013.07.24 15:50:03 1: define: Relais1 error: unknown class RELAIS.
2013.07.24 15:50:03 1: Relais1 error: unknown class RELAIS.
2013.07.24 15:50:03 3: No I/O device found for Relais1
2013.07.24 15:50:02 1: Including ./FHEM/Heizung_90B.cfg
2013.07.24 15:50:02 1: Including ./FHEM/Heizung_90C.cfg
2013.07.24 15:50:02 3: Please define Relais5 first
2013.07.24 15:50:02 1: define: Relais5 error: unknown class RELAIS.
2013.07.24 15:50:02 1: Relais5 error: unknown class RELAIS.
2013.07.24 15:50:02 3: No I/O device found for Relais5
2013.07.24 15:50:02 3: Please define Relais4 first
2013.07.24 15:50:02 1: define: Relais4 error: unknown class RELAIS.
2013.07.24 15:50:02 1: Relais4 error: unknown class RELAIS.
2013.07.24 15:50:02 3: No I/O device found for Relais4
2013.07.24 15:50:02 1: define: PIR error: unknown class adc.
2013.07.24 15:50:02 1: PIR error: unknown class adc.
2013.07.24 15:50:02 3: No I/O device found for PIR
2013.07.24 15:50:02 3: Please define lichtsensor first
2013.07.24 15:50:02 1: define: lichtsensor error: unknown class adc.
2013.07.24 15:50:02 1: lichtsensor error: unknown class adc.
2013.07.24 15:50:02 3: No I/O device found for lichtsensor
2013.07.24 15:50:02 1: define: temp_kessel_out error: unknown class ONEWIRE.
2013.07.24 15:50:02 1: temp_kessel_out error: unknown class ONEWIRE.
2013.07.24 15:50:02 3: No I/O device found for temp_kessel_out
2013.07.24 15:50:02 1: define: temp_vorlauf_ist error: unknown class ONEWIRE.
2013.07.24 15:50:02 1: temp_vorlauf_ist error: unknown class ONEWIRE.
2013.07.24 15:50:02 3: No I/O device found for temp_vorlauf_ist
2013.07.24 15:50:02 1: define: temp_aussen error: unknown class ONEWIRE.
2013.07.24 15:50:02 1: temp_aussen error: unknown class ONEWIRE.
2013.07.24 15:50:02 3: No I/O device found for temp_aussen
2013.07.24 15:50:02 1: define: temp_keller error: unknown class ONEWIRE.
2013.07.24 15:50:02 1: temp_keller error: unknown class ONEWIRE.
2013.07.24 15:50:02 3: No I/O device found for temp_keller
2013.07.24 15:50:02 3: Please define NETIO first
2013.07.24 15:50:02 3: Please define NETIO first
2013.07.24 15:50:02 1: define: NETIO: Error: timeout reading answer for get V
2013.07.24 15:50:02 1: Cannot init NETIO (192.168.178.50:2701), ignoring it
2013.07.24 15:50:02 1: NETIO: Error: timeout reading answer for get V
2013.07.24 15:49:59 2: ECMD Ram used: parse error
2013.07.24 15:49:57 3: ECMD device opened
2013.07.24 15:49:57 3: ECMD opening NETIO (protocol telnet, device 192.168.178.50:2701)
2013.07.24 15:49:57 1: Including ./FHEM/netio.cfg
2013.07.24 15:49:57 3: FB_CALLMONITOR: Anruf read 227 contacts from FritzBox phonebook
Mache ich etwas falsch, oder hat sich bei der definition etwas geändert?
VG
Olaf
das sieht so aus als würde das Device eingangs nicht initialisert worden sein.
daher schlagen die Dafines danach fehl.
Kannst du mal den Auszug darüber senden. Bei der initialisierung von ECMD.
Und stell das loglevel am besten auf 5
Ich hänge nochmal ein Update dran.
Habe nochmal schnell was optimiert. --> neuer Anhang
Hi Ulli,
deine Änderungen haben gewirkt. Verhält sich alles normal.
Bis auf:
2013.07.24 20:18:27 2:
ECMD Ram used: parse error2013.07.24 20:18:27 5:
ECMD (ReadAnswer): <parse error>Hier der Log (Verbose 5):
Zitat2013.07.24 20:18:30 5: Cmd: >define weblink_Rel4 weblink fileplot Log_Rel4:fs20:CURRENT<
2013.07.24 20:18:30 5: Cmd: >attr Log_Rel4 logtype text<
2013.07.24 20:18:30 5: Cmd: >define Log_Rel4 FileLog ./log/Rel4-%Y.log Rel4:.*<
2013.07.24 20:18:30 5: Cmd: >attr n_Rel4 room at_notify<
2013.07.24 20:18:30 5: Cmd: >define n_Rel4 notify Rel4:.* set Relais4 %<
2013.07.24 20:18:30 5: Cmd: >attr Rel4 model fs20st<
2013.07.24 20:18:30 5: Cmd: >attr Rel4 dummy 1<
2013.07.24 20:18:30 5: Cmd: >define Rel4 FS20 304b 10<
2013.07.24 20:18:30 5: Cmd: >attr Relais4 room hidden<
2013.07.24 20:18:30 5: Cmd: >define Relais4 ECMDDevice RELAIS RELAIS4<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_PIR_1 room HZ_Steuerung_90B<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_PIR_1 label "Melder Min $data{min1}, Max $data{max1},Aktuell $data{currval1}"<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_PIR_1 alias Bewegungsmelder<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_PIR_1 weblink fileplot Log_PIR:wl_Log_PIR_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >attr a_PIR room at_notify<
2013.07.24 20:18:30 5: Cmd: >attr a_PIR loglevel 6<
2013.07.24 20:18:30 5: Cmd: >define a_PIR at +*00:00:10 get PIR portvalue<
2013.07.24 20:18:30 5: Cmd: >define Log_PIR FileLog ./log/PIR-%Y.log PIR:.*<
2013.07.24 20:18:30 5: Cmd: >define PIR ECMDDevice adc 6<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_lichtsensor_1 room Wetter_Daten<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_lichtsensor_1 label "Licht-Sensor Min $data{min1}, Max $data{max1},Aktuell $data{currval1} "<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_lichtsensor_1 alias Lichtsensor<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_lichtsensor_1 weblink fileplot Log_lichtsensor:wl_Log_lichtsensor_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >attr a_lichtsensor room at_notify<
2013.07.24 20:18:30 5: Cmd: >attr a_lichtsensor loglevel 6<
2013.07.24 20:18:30 5: Cmd: >define a_lichtsensor at +*00:00:20 get lichtsensor portvalue<
2013.07.24 20:18:30 5: Cmd: >define Log_lichtsensor FileLog ./log/lichtsensor-%Y.log lichtsensor:.*<
2013.07.24 20:18:30 5: Cmd: >attr lichtsensor event-on-change-reading portvalue<
2013.07.24 20:18:30 5: Cmd: >define lichtsensor ECMDDevice adc 7<
2013.07.24 20:18:30 5: Cmd: >attr a_ONEWIRE room at_notify<
2013.07.24 20:18:30 5: Cmd: >attr a_ONEWIRE loglevel 6<
2013.07.24 20:18:30 5: Loading ./FHEM/90_at.pm
2013.07.24 20:18:30 5: Cmd: >define a_ONEWIRE at +*00:02:00 get temp_aussen,temp_keller,temp_vorlauf_ist,temp_kessel_out temp<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_kessel_out_1 room HZ_Steuerung_90B<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_kessel_out_1 label "Kessel-Out Temp Min $data{min1}, Max $data{max1},Aktuell $data{currval1} °C"<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_temp_kessel_out_1 weblink fileplot Log_temp_kessel_out:wl_Log_temp_kessel_out_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >define Log_temp_kessel_out FileLog ./log/temp_kessel_out-%Y.log temp_kessel_out:.*<
2013.07.24 20:18:30 5: Cmd: >define temp_kessel_out ECMDDevice ONEWIRE 10c16c90020800bb<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_vorlauf_ist_1 room HZ_Steuerung_90B<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_vorlauf_ist_1 label "Vorlauf-Ist Temp Min $data{min1}, Max $data{max1},Aktuell $data{currval1} °C"<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_temp_vorlauf_ist_1 weblink fileplot Log_temp_vorlauf_ist:wl_Log_temp_vorlauf_ist_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >define Log_temp_vorlauf_ist FileLog ./log/temp_vorlauf_ist-%Y.log temp_vorlauf_ist:.*<
2013.07.24 20:18:30 5: Cmd: >define temp_vorlauf_ist ECMDDevice ONEWIRE 101e429002080001<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_aussen_1 room Wetter_Daten<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_aussen_1 label "Außen-Temp Min $data{min1}, Max $data{max1},Aktuell $data{currval1} °C"<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_aussen_1 alias Außen-Temperatur<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_temp_aussen_1 weblink fileplot Log_temp_aussen:wl_Log_temp_aussen_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >define Log_temp_aussen FileLog ./log/temp_aussen-%Y.log temp_aussen:.*<
2013.07.24 20:18:30 5: Cmd: >define temp_aussen ECMDDevice ONEWIRE 10cb289002080082<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_keller_1 sortby 1<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_keller_1 room Heizung_90B<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_keller_1 label "Keller Temp Min $data{min1}, Max $data{max1},Aktuell $data{currval1} °C"<
2013.07.24 20:18:30 5: Cmd: >attr wl_Log_temp_keller_1 alias Keller_Temperatur<
2013.07.24 20:18:30 5: Cmd: >define wl_Log_temp_keller_1 weblink fileplot Log_temp_keller:wl_Log_temp_keller_1:CURRENT<
2013.07.24 20:18:30 5: Cmd: >define Log_temp_keller FileLog ./log/temp_keller-%Y.log temp_keller:.*<
2013.07.24 20:18:30 5: Loading ./FHEM/67_ECMDDevice.pm
2013.07.24 20:18:30 5: Cmd: >define temp_keller ECMDDevice ONEWIRE 107b2d9002080057<
2013.07.24 20:18:30 5: Cmd: >attr NETIO room hidden<
2013.07.24 20:18:30 5: NETIO: get state postprocessor defined as {my $retval = "closed";my $ipwert=substr($_, 13, 2);$ipwert = hex($ipwert) & 0x%InPort;$retval = "open" if ($ipwert > 0);$retval;}
2013.07.24 20:18:30 5: NETIO: evaluating >get state postproc {my $retval = "closed";my $ipwert=substr($_, 13, 2);$ipwert = hex($ipwert) & 0x%InPort;$retval = "open" if ($ipwert > 0);$retval;}<
2013.07.24 20:18:30 5: NETIO: get state command defined as {"io set ddr 0 F0 %InPort\nio get pin 0"}
2013.07.24 20:18:30 5: NETIO: evaluating >get state cmd {"io set ddr 0 F0 %InPort\nio get pin 0"}<
2013.07.24 20:18:30 5: NETIO: parameters are InPort
2013.07.24 20:18:30 5: NETIO: evaluating >params InPort<
2013.07.24 20:18:30 5: NETIO: adding new class CONTACT from file ./contacts.classdef
2013.07.24 20:18:30 5: NETIO: get portvalue postprocessor defined as {hex(trim("$_"))}
2013.07.24 20:18:30 5: NETIO: evaluating >get portvalue postproc {hex(trim("$_"))}<
2013.07.24 20:18:30 5: NETIO: get portvalue command defined as {"adc get %PortID"}
2013.07.24 20:18:30 5: NETIO: evaluating >get portvalue cmd {"adc get %PortID"}<
2013.07.24 20:18:30 5: NETIO: parameters are PortID
2013.07.24 20:18:30 5: NETIO: evaluating >params PortID<
2013.07.24 20:18:30 5: NETIO: adding new class adc from file ./classdef.netio.adc
2013.07.24 20:18:30 5: NETIO: get temp command defined as {"1w get %devID"}
2013.07.24 20:18:30 5: NETIO: evaluating >get temp cmd {"1w get %devID"}<
2013.07.24 20:18:30 5: NETIO: set messen command defined as {"1w convert"}
2013.07.24 20:18:30 5: NETIO: evaluating >set messen cmd {"1w convert"}<
2013.07.24 20:18:30 5: NETIO: parameters are devID
2013.07.24 20:18:30 5: NETIO: evaluating >params devID<
2013.07.24 20:18:30 5: NETIO: adding new class ONEWIRE from file ./onewire.classdef
2013.07.24 20:18:30 5: NETIO: get state command defined as {"pin get %RelaisPort\n"}
2013.07.24 20:18:30 5: NETIO: evaluating >get state cmd {"pin get %RelaisPort\n"}<
2013.07.24 20:18:30 5: NETIO: set toggle postprocessor defined as {s/([on|;]*)/success/; "$_" eq "success" ? "on" : "off";}
2013.07.24 20:18:30 5: NETIO: evaluating >set toggle postproc {s/([on|;]*)/success/; "$_" eq "success" ? "on" : "off";}<
2013.07.24 20:18:30 5: NETIO: set toggle command defined as {"pin toggle %RelaisPort\n"}
2013.07.24 20:18:30 5: NETIO: evaluating >set toggle cmd {"pin toggle %RelaisPort\n"}<
2013.07.24 20:18:30 5: NETIO: set off postprocessor defined as {s/([off|;]*)/success/; "$_" eq "success" ? "off" : "error";}
2013.07.24 20:18:30 5: NETIO: evaluating >set off postproc {s/([off|;]*)/success/; "$_" eq "success" ? "off" : "error";}<
2013.07.24 20:18:30 5: NETIO: set off command defined as {"pin set %RelaisPort off\n"}
2013.07.24 20:18:30 5: NETIO: evaluating >set off cmd {"pin set %RelaisPort off\n"}<
2013.07.24 20:18:30 5: NETIO: set on postprocessor defined as {s/([on|;]*)/success/; "$_" eq "success" ? "on" : "error";}
2013.07.24 20:18:30 5: NETIO: evaluating >set on postproc {s/([on|;]*)/success/; "$_" eq "success" ? "on" : "error";}<
2013.07.24 20:18:30 5: NETIO: set on command defined as {"pin set %RelaisPort on\n"}
2013.07.24 20:18:30 5: NETIO: evaluating >set on cmd {"pin set %RelaisPort on\n"}<
2013.07.24 20:18:30 5: NETIO: parameters are RelaisPort
2013.07.24 20:18:30 5: NETIO: evaluating >params RelaisPort<
2013.07.24 20:18:30 5: NETIO: adding new class RELAIS from file ./relais.classdef
2013.07.24 20:18:30 5: Cmd: >attr NETIO classdefs RELAIS=./relais.classdef:ONEWIRE=./onewire.classdef:adc=./classdef.netio.adc:CONTACT=./contacts.classdef<
2013.07.24 20:18:30 2: ECMD version:
2013.07.24 20:18:27 5: ECMD reading answer for get V...
2013.07.24 20:18:27 2: ECMD Ram used: parse error
2013.07.24 20:18:27 5: ECMD (ReadAnswer): <parse error>
2013.07.24 20:18:27 5: ECMD: PARTIAL/RAW: /parse error
2013.07.24 20:18:27 5: ECMD reading answer for get ram...
2013.07.24 20:18:25 5: ECMD reading answer for get clear...
2013.07.24 20:18:25 3: ECMD device opened
2013.07.24 20:18:25 3: ECMD opening NETIO (protocol telnet, device 192.168.178.50:2701)
2013.07.24 20:18:25 5: Loading ./FHEM/66_ECMD.pm
2013.07.24 20:18:25 5: Cmd: >define NETIO ECMD telnet 192.168.178.50:2701<
2013.07.24 20:18:25 1: Including ./FHEM/netio.cfg
2013.07.24 20:18:25 5: Cmd: >include ./FHEM/netio.cfg<
Hallo und vielen Dank für die Erweiterung der Module,
ich habe drei AVR`s im Einsatz und werde versuchen am Wochenende die neuen Module mal zu testen.
Melde mich sobald ein Ergebnis vorliegt.
Super das ihr euch als Tester bereit erklärt!
Bzgl. der neuen Funktion müsst ihr in die classdef Datei die Befehle die Ihr empfangen und ausgewertet haben möchtet wie folgt definieren
recv <name> cmd {"<Empfangeer String, kann wie set auch parameter enthalten>"}
(gleich dem set Befehl)
postproc sollte auch funktionieren
Viel Spass.
Hi Ulli,
habe meine classdef für den ADC geändert:
Zitat# Uebergabeparameter Portnummer des internen Analogeingangs
params PortID
#
#
#get portvalue cmd {"adc get %PortID"}
#get portvalue postproc {hex(trim("$_"))}
#
recv portvalue cmd {"adc get %PortID"}
recv portvalue postproc {hex(trim("$_"))}
Sind die änderungen so richtig?
Muss ich die Eingänge jetzt anders abfragen?
VG
Olaf
achso ja und Ihr müsst den MatchString an eure einzulesende Commando Syntax anpassen in der ECMDDevice_Initialize
Hat jemand eine Idee wir man den WErt für $hash->{Match} aus einem Attribut oder aus der Classdef setzen könnte?
Hi ollir,
nein deine Konfiguration einfach so lassen wie sie war um deine ursprünglichen Funktionen weiter zu verwenden.
Hinzu kommt das du zusätzliche recv Kommandos definieren kannst, welche darüber dann den empfangenen Daten zugeordnet werden können.
Ich habe dies getrennt, da ich folgende konfiguration benötige
set on cmd {"rfm %Protocol %HouseCode %Device 1"}
set off cmd {"rfm %Protocol %HouseCode %Device 0"}
recv toggle cmd {"rfm %Protocol %HouseCode %Device 1"}
so kann ich gezielt meine Geräte an aus aus schalten und den Empfang der Daten zu einem Toggeln verwenden. :)
Kannst Du mal bitte eine Schritt-für-Schritt Anleitung für die Verwendung Deiner geänderten Module erstellen? Am Besten ausgehend vom Beispieleintrag im WIKI.
Mich interessiert vor allen Dingen die Nutzung von ADC Eingängen am NetIO. Irgendwie verstehe ich noch nicht, was jetzt grundlegend anders ist als vorher. Und im NetIO steht immer ein parse Error, obwohl die Eingänge genau wie vorher gelesen werden können.
Viele Grüße
Udo
hallo zusammen,
sorry für die späte Antwort.
Aber im folgenden noch einmal eine kurze Beschreibung meiner Read Erweiterung.
Das Define bleibt wie im Wiki beschrieben.
z.B. define HomeControl ECMD serial /dev/ttyUSB0@57600
Die Classdefs ebenfalls
z.B. attr HomeControl classdefs RFM12=./config/rfm.classdef
Neu ist ein Attributm, welches eine Totzeit verhindert falls das am USB hängende Gerät bei Write Befehlen keine Antwort zurückmeldet.
--> attr HomeControl noWriteFeedback 1
Die Device Definition bleiben ebenfalls gleich.
z.B. define WZ_RFM_Remote_A ECMDDevice RFM12 1 10010 A
Neu ist die Möglichkeit in der classdef Datei Kommandos zu definieren, welche ohne einen Trigger von fhem eingelesen werden können und weiter verarbeitet werden.
recv on cmd {"rfm %Protocol %HouseCode %Device 1"}
d.h. wenn das am USB hängende Gerät folgendes Kommando versendet "rfm 1 10010 A 1" wird dieses Rückwerts über einen "Dispatch" aufgelöst (in unserem Beispiel zu "WZ_RFM_Remote_A").
Wichtig dabei ist in der Datei "67_ECMDDevice.pm" die Variable "$MatchRegExString" auf das zu empfangene Kommando (als RegEx) abzugleichen.
Zum Verständnis, ich verwende diese Erweiterung um IR Kommandos oder Funk Kommandos in fhem verarbeiten zu können.
Ich hoffe das hilft euch weiter!
Hallo,
wo stehen wir denn in Sachen Test? Kann ich ohne Störungen für bestehende Installationen befürchten zu müssen das veränderte Modul einchecken (bräuchte dann aber nochmal die aktuelle Version hier als Anhang)?
Viele Grüße
Boris
Hallo Boris,
meiner Meinung nach kannst du die Aktuallisierung hochladen.
Ich habe ja an der derzeitigen Funktion nichts geändert, nur eine hinzugefügt.
Nämlich die "recv" Funktionalität, daher sollte keine Gefahr für aktuelle Nutzer ausgehen.
Ich habe die Files nochmal gecleaned und angehängt.
Super das du diese hochlädst, dann kann ich wieder ein update machen :)
Hallo Ulli,
Zitat von: ulli schrieb am Di, 20 August 2013 18:52Ich habe die Files nochmal gecleaned und angehängt.
ich mußte die Ermittlung von RAM und Version auskommentieren, weil mein Gerät diese Befehle nicht kennt. Da ECMD ja (trotz des Namens) ein generisches Modul für alle nach dem Frage-Antwort-Prinzip arbeitenden Geräte ist, sollten wir keine Annahmen über vorhandene Befehle treffen.
Müßte nicht noch die Dokumentation ergänzt werden?
Viele Grüße
Boris
Die Ram- und Versionsabfrage habe ich doch in den letzten Files auskommentiert.
Ist es im SVN? Würde dann ein update machen und nochmal testen ob alles gut gegangen ist...
Die Dateien im Beitrag vom 20. August haben tatsächlich die Abfragen auskommentiert. Was ich da wohl heruntergeladen habe???
Kannst Du bitte noch die Dokumentation für recv ergänzen? Danke.
Viele Grüße
Boris
wie und wo mach ich das?
Zitat von: ulli schrieb am Mo, 26 August 2013 20:35wie und wo mach ich das?
Am Ende der Dateien (ECMD, ECMDDevice) steht der HTML-Kode für die commandref. Dort einfach die Erweiterungen ergänzen.
Aus dem Verzeichnis
fhem heraus dann
contrib/commandref_join.pl aufrufen, auf unbalancierte Tags achten, und das Ergebnis in
docs/commandref.html zur Korrektur lesen.
Viele Grüße
Boris
Hallo Ulli,
ich würde das erweiterte Modul gerne einchecken. Wenn Du mir die Änderungen in einem Post zusammenfaßt, ergänze ich die Doku auch selbst.
Viele Grüße
Boris
Hallo
mal ne dumme Frage.
Wie kann ich denn meine avr-netios dazu bewegen mir Portänderungen , ir-befehle etc. selbstständig übers netzwerk zukommen zu lassen?
Läuft dass über ein Control6 script? Versteh dass Prinzip nicht so richtig.
Bisher setzte ich eine HTTPlog meldung auf einen Fhem-Dummy ab um promte Änderungen gemeldet zu bekommen und alle paar minuten eine Rundfrage über die Stati der einzelnen ports und Devices, was Fhem doch schon gewaltig ausbremst.
Such schon seit ewigkeiten nach einer Lösung, die es im CUNO schon gibt.
ich würde die version mit recv funktionalität gerne für meine ultraschall füllstandsmessung verwenden. wie bekommen wir diese version eingecheckt?
gruss
andre
ps: falls jemand ähnliches vorhar: mein sensor ist ein per usb angebundener arduino nano der über recht viele messungen mittelt und dann mit temperatur kompensation die entfernung berechnet. das liefert auch mit einem sr04 recht stabile ergebnisse. nebenbei wird noch die vcc gemessen weil es sehr wichtig ist sicherzustellen das die versorgungsspannung hoch genug ist. ein aktiver usb hub direkt in arduino nähe ist zwingend nötig. 5m usb kabel reichen schon um die spannung so weit abfallen zu lassen das der us sensor nicht mehr richtig arbeitet.
ich bin mir noch nicht sicher ob ich die volumen berechnung auch auf dem sketch oder in fhem machen soll.
Zitat von: justme1968 schrieb am Mo, 09 September 2013 14:18ich würde die version mit recv funktionalität gerne für meine ultraschall füllstandsmessung verwenden. wie bekommen wir diese version eingecheckt?
Indem jemand die Doku ergänzt oder mir sagt, was ich ergänzen soll.
Grüße
Boris
Ich bin gerade noch im Urlaub. .. ich helfe euch Ende der Woche ;)
Zitat von: ulli schrieb am Sa, 17 August 2013 21:44hallo zusammen,
sorry für die späte Antwort.
Aber im folgenden noch einmal eine kurze Beschreibung meiner Read Erweiterung.
Das Define bleibt wie im Wiki beschrieben.
z.B. define HomeControl ECMD serial /dev/ttyUSB0@57600
Die Classdefs ebenfalls
z.B. attr HomeControl classdefs RFM12=./config/rfm.classdef
Neu ist ein Attributm, welches eine Totzeit verhindert falls das am USB hängende Gerät bei Write Befehlen keine Antwort zurückmeldet.
--> attr HomeControl noWriteFeedback 1
Die Device Definition bleiben ebenfalls gleich.
z.B. define WZ_RFM_Remote_A ECMDDevice RFM12 1 10010 A
Neu ist die Möglichkeit in der classdef Datei Kommandos zu definieren, welche ohne einen Trigger von fhem eingelesen werden können und weiter verarbeitet werden.
recv on cmd {"rfm %Protocol %HouseCode %Device 1"}
d.h. wenn das am USB hängende Gerät folgendes Kommando versendet "rfm 1 10010 A 1" wird dieses Rückwerts über einen "Dispatch" aufgelöst (in unserem Beispiel zu "WZ_RFM_Remote_A").
Wichtig dabei ist in der Datei "67_ECMDDevice.pm" die Variable "$MatchRegExString" auf das zu empfangene Kommando (als RegEx) abzugleichen.
Zum Verständnis, ich verwende diese Erweiterung um IR Kommandos oder Funk Kommandos in fhem verarbeiten zu können.
Ich hoffe das hilft euch weiter!
Hier ist aber alles beschrieben!
Hallo macmattes, justme1968,
nur um Missverständnisse zu vermeiden, eine Frage:
Wie sieht denn das von eurem AVR versendete Kommando, welches Ihr verarbeiten wollt aus?
Also die Syntax inkl. Beispiel?
Das Kommando wird zu einem beliebigen Zeitpunkt von eurem AVR versendet, also kein Query, richtig?
Poste mal deine bestehenden ECMD Zeilen und die classdef Datei.
ja. die idee ist das der arduino selbständig die messwerte sendet fhem aber z.b. die temperatur und das sendeintervall per set ändern kann. was meinst du für missverständnisse?
die fhem konfiguration und die classef zeilen kann ich dir zeigen sobald ich etwas habe das halbwegs funktioniert.
aus irgendeinem grund hängt sich mein mac komplett auf wenn ich ein paar zeilen mit dem ECMDDevice lese. ECMD raw geht noch ohne probleme. per terminal programm geht es auch. und alle anderen USB devices (1-2 panstamps und 1 jeelink) laufen problemlos mit fhem. ich bin noch etwas ratlos.
gruss
andre
hallo
auf meinen avrnetio läuft ethersex und ich übertrage die Eingänge mit httplog auf je einen Dummy je Eingang
Auszug aus der Control6 Datei
>>>>>>
#include "protocols/httplog/httplog.h"
ON PIN_FALLING(Eingang0) DO
httplog("cmd=set+avrnetio07_Eingang0+on");
END
<<<<<<
von Fhem aus steuer ich die Ausgänge am AVR mit Namedpins
Auszug aus der classdefs
>>>>>>>
params name
#set named pin on########
set on cmd {"pin set %name on"}
<<<<<<<
wenn ich es richtig verstanden habe dann baut ECMD im Fhem jeweils eine telnet verbindung auf, und setzt dort die befehle ab und wartet auf die Logausgabe.
hoffe ab hier versteh ich es dann richtig, read liest auf der Telnetsession mit und reagiert dann entsprechend wenn definierte werte reinkommen?
denke so läufts ja auch beim CUNO , da kommen antworten wie T...... und I......... und und und
wäre ja schon logisch wenn mein Ethersex dass auch machen würden, also Pinänderungen als P...... oder die Daten vom IR Sensor als I....... oder in bestimmten abständen die werte der gefundenen Ds1820 , oder DHT22. oder oder oder
wenn meine denke so richtig ist, dann stellt sich für mich nun die Frage, ob dass mit Control6 zu machen ist oder wie sonst?
dann würden die Dummys wegfallen und man müsste die nicht in jedem Ethersex fix hinterlegen.
mit ein bisschen pinänderungen müsste CULFW vom Cuno doch eigentlich auch auf einem avrnetio von pollin laufen, wenn man den 1284p benutzt, nur sind dann eben nicht die Eingänge-Ausgänge oder weitere Module so einfach zu setzen wie beim UR-Ethersex, wenn dass überhaupt geht.
mit Control6 tu ich mich noch sehr schwer, weil im Verhältnis zu den Möglichkeiten zu wenig Dokus existieren.
hallo
könnte jemand antworten und meine Gedankengänge kurz bestätigen oder widerrufen.
So absolut ohne wink mit dem Zaunpfahl komm ich nicht weiter. Danke.
was ist die Frage?
Hallo Ulli
hoffe du kannst mir einfach beim verständnis, der Übergabe der Werte weiterhelfen.
Vielleicht etwas unbeholfen ausgedrückt ab so in etwa wie ich es verstehe.
"wenn ich es richtig verstanden habe dann baut ECMD im Fhem jeweils eine telnet verbindung auf, und setzt dort die befehle ab und wartet auf die Logausgabe.
hoffe ab hier versteh ich es dann richtig, read liest auf der Telnetsession mit und reagiert dann entsprechend wenn definierte werte reinkommen?"
wenn dass soweit richtig wäre, wie überrede ich dann meine Ethersex dazu,auf diese Telnetsession zu schreiben wenn sich was auf den Pins tut?
Wie läuft das im Cuno,dass doch eigentlich ein Ethersex ist?
besten dank für ein paar erklärende tips.
Ich habe die erweiterten Module von Ulli getestet. Soweit funktioniert alles wie vorher.
Jetzt möchte ich die recv ausprobieren.
Zum testen habe ich einen NetIO mit ethersex wie mi Wikki beschrieben in der 'fhem.cfg' wie folgt definiert
define NETIO93 ECMD telnet IP:PORT
attr NETIO93 classdefs ECMD93C=ECMD93C.classdef
define PORT93C1 ECMDDevice ECMD93C 01
in der 'ECMD93C.classdef' steht
params PIN
set on cmd {"io set ddr 2 ff\nio set port 2 %PIN %PIN"}
set on postproc {substr($_, 0, 2) eq "OK" ? "" : "$_";}
set off cmd {"io set ddr 2 ff\nio set port 2 00 %PIN"}
set off postproc {substr($_, 0, 2) eq "OK" ? "" : "$_";}
weiterhin kann ich mit der Funktion
get status cmd {"io get port 2"}
get status postproc {\
my $retval = "off";\
my $portwert = substr($_, 10, 2);\
$portwert = hex($portwert) & hex($PIN);\
$retval = "on" if ($portwert > 0);\
$retval;}
Der NetIO gibt als Antwort 'port 2 0x01 # also den Port 2 als Hex.
Wenn ich es richtig verstanden habe, kann ich mit der neuen Funktion eine Statusänderung erhalten, ohne den Port abzufragen.
Dazu muss der NetIO bei einer Änderung des Zustandes am PIN etwas ausgeben. Kann mir jemand an einem kurzen Beispiel sagen, was der NetIO ausgeben muss, und was ich dann in 'recv status (on?) cmd {???????????}' eintragen muss? Laut Anleitung "io set port 2 %PIN %PIN"? Das ist mir noch nicht so ganz klar.
Muß ich irgendwann erst mal recv (NAME) on aufrufen?
Ich hoffe das Thema ist noch aktuell.
mfg Tom_S
So. habe es jetzt hin bekommen. Super Erweiterung - sehr gut. Danke an Ulli
aber das
achso ja und Ihr müsst den MatchString an eure einzulesende Commando Syntax anpassen in der ECMDDevice_Initialize
sollte noch ein bischen genauer beschrieben werden. Dann wäre es einfacher.
LG Tom_S
hallo,
wollte noch mal fragen, ob noch an dieser Version gearbeitet wird. Bei mir funktioniert sie nach den Erklärungen hier im Forum. Das Einlesen von Analogwerten, was justme1968 gern verwenden würde, bekomme ich nicht hin. Der Ausgabewert des Controller muß genau auf den String passen, dann wird das Kommando ausgeführt.
Hat da schon jemand etwas hinbekommen?
Zitat von: Tom_S am 28 Oktober 2013, 09:43:42
wollte noch mal fragen, ob noch an dieser Version gearbeitet wird.
Das würde mich auch interessieren, da ich gerade an der Stelle hänge.
Zitat von: Tom_S am 28 Oktober 2013, 09:43:42
Bei mir funktioniert sie nach den Erklärungen hier im Forum.
Wo lässt sich das nachlesen? Vielen Dank vorab!
Zitat von: Tom_S am 15 Oktober 2013, 19:38:03
achso ja und Ihr müsst den MatchString an eure einzulesende Commando Syntax anpassen in der ECMDDevice_Initialize
sollte noch ein bischen genauer beschrieben werden. Dann wäre es einfacher.
Das genau ist neben der Umstellung auf DevIO.pm der andere Grund, warum ich die Erweiterung nicht in das offizielle Modul übernommen habe. Der MatchString gehört in die ClassDef. Und das ist mir im Moment zuviel Arbeit, da ich das Modul nur im Dialogmodus benötige.
Freiwillige vor!
Viele Grüße
Boris
Hallo,
auch ich benutze 2 AVM NetIO Systeme. Hier brauche ich die Funktionen Port setzen, Port lesen und Onewire. Ich weiss nicht , ob ich die neue Funktion richtig verstanden habe. :-\
Auf den NetIO´s läuft, die wie im Ethersex Wiki beschriebene, geflashte Ethersex Software. Ich kann Ausgänge schalten , Onewire Werte empfangen , Meldungen am das LCD Display senden, und Eingänge auslesen. Das läuft auch soweit alles. :D Bis auf den Nachteil, daß die Eingänge zum Lesen ständig durch FHEM gepollt werden müssen. :(
Bei mir läuft da zum Beispiel eine Heizungssteuerung mit. Mit den Onewire Temp Sensoren nehme ich die Vor,Rücklauf, Kessel und Brauchwasser Werte auf. Über einen Ausgangsport schalte ich von Tag auf Nachtabsenkung um. Denn Brenner "Fehlerausgang" frage ich über einen Eingangsport ab. Leider muss ich deshalb pollen (alle 3 min für Temp Werte und Brennerstatus). Auch würde ich gerne die Brenner Laufzeit über einen weiteren Port ermitteln, doch um da noch recht genaue Ergebnisse zu erhalten, müsste ich den Poll sehr kurz einstellen, was FHEM dann doch sehr belasten würde.
Nun meine Frage: Kann ich mit dieser Erweiterung die Eingänge vom NetIO so in FHEM einbinden, daß bei einer Änderung des Portzustands automatisch über ein notify eine Aktion durchgeführt wird und dann nur noch die Temp Werte pollen.
Könnt Ihr mir dann dafür ein Beispiel geben, wie der Befehl in FHEM aussieht, und wie der Eitrag in der ECMDDevice.pl angepasst werden muss.
In dem Beispiel wurden ja nur Ausgangsport überwacht. Der Status sollte ja bekannt sein.
MfG Uwe
hallo zusammen,
warum wird das attribut NoWriteFeedback nicht in das offizielle modul übernommen? das wird nur am anfang erwähnt und dann nicht mehr?
gruß
Hallo an alle,
ich habe ein AVR-Net-IO im Gartenhaus als Steuerung von Springbrunnen und Bachlauf. Das ganze läuft direkt per Tasten für Bachlauf Taste für Springbrunnen. zusätlich kann ich über FHEM beides ein/ausschalten.
Wenn ich aber die Tasten benutze um ein/auszuschalten, wird dies nicht in FHEM angezeigt. Wenn ich das richtig verstanden habe kann ich dieses Modul hier verwenden um genau das abzubilden. (Polling im 1min Takt auf die Schaltzustände der Relais, möchte ich auch nicht machen)
Was fehlt damit das hier benutzt werden kann bzw. als offiz. Teil in FHEM aufgenommen werden kann? Sonst ist das ganze ja nach einem Update wieder weg, oder?
Grüße
1wire
siehe bitte meinen Beitrag vom 16.11. in diesem Thread...
Grüße
Boris
ok. Soweit klar.
Also da ich das unbedingt umsetzen will und so gar keine Ahnung habe, werde ich parallel alles dokumentieren wie das geht. Evtl. können wir dann daraus die offiz. Version fertigstellen bzw. die fehlenden Dinge nachliefern.
Also:
ich hab jetzt diesen Thread mehrfach durchgelesen.
Ich hab jetzt die aktuellen Module vom 20.August bei mir in FHEM drin. Shutdown restart und alles funktioniert wie vorher.
Welche Vorraussetzungen müssen im Ethersex konfiguriert sein, damit der AVR z. B.: den Tastendruck PA0 sendet? Ich hab (Simple) I/O abstraction model (Port I(O) in der Firmware aktiviert.
viele Grüße
Zitat von: Tom_S am 15 Oktober 2013, 19:38:03
So. habe es jetzt hin bekommen. Super Erweiterung - sehr gut. Danke an Ulli
aber das
achso ja und Ihr müsst den MatchString an eure einzulesende Commando Syntax anpassen in der ECMDDevice_Initialize
sollte noch ein bischen genauer beschrieben werden. Dann wäre es einfacher.
LG Tom_S
Hallo Tom,
da ich auch gerne eine Änderung von Port Pins im NetIO an mein fhem schicken möchte, würde mich mal interessieren "
wie" du es hin bekommen hast. Du hast leider nur geschrieben "
dass" Du hes hin bekommen hast. :)
Gruß,
Manfred
ich habe jetzt eine Lösung gefunden wie ich Statiänderungen vom AVR-Netio an Fhem senden kann.
Hier mein Beitrag in einem anderen Thread:
http://forum.fhem.de/index.php/topic,16618.msg126005.html#msg126005
na dann, Gute Nacht ;)
Hi Ulli,
haben diesen vielversprechenden Ansatz gefunden. Ich würde ihn nutzen um ein paar dig. Eingänge, die üben einen TCP-Server ihren Zustand melden in FHEM zu integrieren. Hat also nichts mit AVR-NET-IO etc. zu tun. Das Prinzip ist aber identisch zu Deinem IR-Empfang.
Was ist denn aus Deinen Modifikationen geoworden. Passt alles nicht mehr zum aktuellen Code. Leider. Willst Du da vielleicht nochmal nachziehen?
Matthias