Debugging und Testen von Modulen

Begonnen von Sidey, 18 Juli 2015, 21:01:28

Vorheriges Thema - Nächstes Thema

Sidey

Hallo,

ich entwickele gerade ein Modul (Signalduino).

Jetzt bekomme ich von freundlichen Anwendern auch Debug Logs etc.

Jetzt Frage ich mich, wie debugge ich am besten.
Mein Modul empfängt in der Regel Daten von einem IO Device an einem seriellen Port.
Jetzt würde ich gerne Daten manuell an das Modul senden, quasi die Funktion des IO Device simulieren.

Das Fhem Modul alleine, kann ich ja nicht nutzen , da die Fhem Funktionen fehlen.

Gibt es da schon einen Weg, der vorgesehen ist oder wie macht ihr das?



Vermutlich sehe ich den Wald vor Bäumen nicht.
Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

justme1968

wenn du unter linux entwickelst kannst du z.b. mit mkfifo ein fifo anlegen das du beim define als namen des device angeben kannst wenn du directio mit angibst. da kannst du dann von einer anderen shell einfach rein cat-en. das habe ich damals beim jeelink modul gemacht und konnte ganz ohne echte hardware das modul bauen. mir hat nur jemand die nachrichten per mail gesendet.

wenn dein modul netzwerk devices unterstützt kannst du das gleiche mit netcat erreichen.

oder du baust ein set <device> received um die nachricht von hand zu simulieren und an parse weiter zu geben. das habe ich im LIGHTIFY so gemacht.

die ersten beiden varianten sind gut wenn es viele und/oder lange nachrichten sind, das set funktioniert gut wenn es wenige und kurze nachrichten sind.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

Sidey

Hallo Andre,

Das war genau der Tip den ich gesucht hatte.
Ich habe es über DirectIO und mkfifo gemacht.

Ich musste an meinem Modul einen kleinen hack einbauen, da das Modul üblicherweise ein paar Status Informationen abfragt bevor es läuft.

Prinzipiell wäre das ja auch was fürs Wiki oder?


Bei meinen Versuchen ist mir leider aber eines aufgefallen.
Wenn ich versuche in der Delfine Subroutine Attribute aus zu lesen, dann sind die nie gesetzt.
So wie ich das sehe, funktioniert da irgendwas nicht.

Ab wann kann man denn Attrinute abfragen?

Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

justme1968

attribute sind wärend des define nich nicht gesetzt. das passiert erst später. du bekommst das über die attrFn mit.

wenn du du variante mit netcat nimmst geht das auch bidirektional und du hast den vorteil das dein modul auch einen usb stick der per ser2net eingebunden ist ansprechen kann. in DevIo ist schon alles vorhanden das du dafür brauchst.

gruss
  andre
hue, tradfri, alexa-fhem, homebridge-fhem, LightScene, readingsGroup, ...

https://github.com/sponsors/justme-1968

rudolfkoenig

Ich debugge sowas bei physiklischen/logischen Modulen (z.Bsp. ZWDongle/ZWave) indem ich das in der Detail-Ansicht des physikalischen Moduls sichtbare RAWMSG (steht auch in dem mit verbose 5 erstellten Log), mit Dispatch nochmal versende:
{ Dispatch($defs{ZWDongle}, "00040009083202211200000000", undef) }

Sidey

Hi,

das Dispatch gibst Du direkt im FHEM an?
Wenn ich jetzt den Programmablauf richtig interpretiert habe, dann kann man damit nur logische Module verarbeiten, da die Physischen die Daten von einem device erwarten.

Korrigiere  mich, wenn ich etwas falsch verstanden habe.


Grüße Sidey
Signalduino, Homematic, Raspberry Pi, Mysensors, MQTT, Alexa, Docker, AlexaFhem

Maintainer von: SIGNALduino, fhem-docker, alexa-fhem-docker, fhempy-docker

rudolfkoenig

@Sidey: beide Vermutungen sind korrekt.

uniqueck

Ist zwar schon etwas länger her, dass hier jemand was geschrieben hat, aber ich denke es passt ganz gut.
Ich Stand letztens auch wieder davor wie teste ich bei einer Änderung jedes mal aufs neue, ob das Modul noch das tut was es tun soll.
Da habe ich angefangen auf Basis von shunit2 ein bisschen die Readings zu testen und davor die FHEM Instanz durchzustarten und eine neues Device angelegt, ein update durchgeführt die Readings geprüft, das devices wieder gelöscht.

Funktioniert eigentlich ganz gut, gibt allerdings noch so ein paar Fallstricke, wie das beeinflußen der Systemzeit und soweiter, wenn es jemanden interessiert, einfach Bescheid geben.

Gruß uniqueck / Constantin