55_SMS2OOL - mit SMSTOOLS SMS-Nachrichten Senden und Empfangen (pre-Alpha)

Begonnen von MichaelPaul, 13 Mai 2017, 00:34:03

Vorheriges Thema - Nächstes Thema

MichaelPaul

Sehr geehrte Damen und Herren,
nachdem mir nahegelegt worden ist mein Anliegen diesem Forum mitzuteilen, habe ich mich dann nun als neues Mitglied angemeldet.

Ich bin auf der Suche nach einer Lösung mit denen FHEM auf die Funktionen von SMSTOOLS zugreifen kann.
SMS-Nachrichten sollen empfangen und ausgewertet werden und auch sollen SMS-Nachrichten versendet werden.
Darüber hinaus soll auch der aktuelle Kontostand einer Prepaid-Karte gelegentlich abgefragt werden und auch darauf reagiert werden können.

Aktuell habe ich einen Prototyp eines solchen Moduls erstellt mit dem diese Anforderungen bereits abgebildet werden.

Der Einsatz von INTERNALS, READINGS und auch den ATTRIBUTEN ist mir weitgehend klar.
Zu einigen Problemstellungen diesbezüglich kann ich jedoch keine passende und effiziente Lösung finden.

Die Konfigurationsdatei der SMSTOOLS - also die /etc/smsd.conf - wird innerhalb des "X_Define" erwartet, dessen Inhalte werden als Parameter eingelesen und die Parameter werden dann in der Sektion INTERNALS abgelegt. Es handelt sich dabei um die Verzeichnisangaben zu Incoming, Sent, Outgoing und Statefile.

Die Readings greifen dann auf diese Verzeichnisangaben die in den INTERNALS definiert wurden zu um die SMS-Nachrichten einzulesen und auszuwerten.

Die Frage die sich mir stellt ist:
Was passiert nach einem unkontrollierten Absturz/Neustart des Systems und wie kann man realisieren, dass die INTERNALS und auch die READINGS - die ja beim Anlegen des <Device> mit X_Define angelegt worden sind - wiederhergestellt werden?

Grüße,
Michael Paul

CoolTux

#1
Hallo und herzlich willkommen.

Schade das Du nicht gefragt hast ob es sowas in der Art schon gibt, dann hättest Dir bisschen Arbeit gespart und wir zwei hätten Deine Wünsche in AMAD einbauen können  ;D

Aber da Du nun schon was hast hier ein paar Antworten zu Deinen Fragen.

Die Readings werden im statefile zwischen gespeichert. Attribute und Internals werden beim Neustart neu angelegt, da die DefFn ausgeführt wird.



Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MichaelPaul

Hallo CoolTux,
vielen Dank für deine Reaktion.

Meinem x_Define werden beim Aufruf manuell Parameter übergeben und diese Parameter werden dann - da sich diese niemals ändern werden - als INTERNALS gespeichert. 

define SMS_DEVICE SMS4FHEM CONFIG=/etc/smsd.conf MODUL=GSM1 TO=49163xxxxxxx

Werden denn auch diese manuell an x_Define übergebenen Parameter bei einem Absturz/Neustarts des Systems berücksichtigt und dann erneut als INTERNALS gespeichert.

Die Frage stellt sich mir, da diese Parameter ja nicht in der x_Define-Funktion definiert worden sind.

CoolTux

Guten Morgen,

In der FHEM Config wird

define SMS_DEVICE SMS4FHEM CONFIG=/etc/smsd.conf MODUL=GSM1 TO=49163xxxxxxx

abgespeichert. Also genau das was Du als define Befehl per Hand eingegeben hast. Und somit wird das bei jedem FHEM Start wieder ausgeführt. Probiere es doch einfach aus.
Du liest ja in der DefFn die Übergabe ein.

Ansonsten zeig einfach mal Deinen Code von der DefFn Funktion.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

rudolfkoenig

ZitatWerden denn auch diese manuell an x_Define übergebenen Parameter bei einem Absturz/Neustarts des Systems berücksichtigt und dann erneut als INTERNALS gespeichert.
FHEM speichert beim Ausfuehren des Kommandos save zwei Dateien, fhem.cfg und fhem.state. fhem.cfg enthaelt alle Definitionen und Attribute (also das, was der Benutzer normalerweise aendert), fhem.state alle Readings und das STATE Internal (also das, was das Programm aendert, und nach dem Neustart einlesen will). Weiterhin wird beim kontrollierten Beenden von FHEM fhem.state gespeichert, fhem.cfg nicht.

save wird manuell ausgefuehrt, oder bei der ausgelieferten Voreinstellung nach Anlegen eines Geraetes durch autocreate.

Bei einem Absturz wird nichts gespeichert, es gelten dann die zuletzt gespeicherten Versionen von fhem.cfg & fhem.state

SteveLee

Wenn du einen Beta Tester benötigst... melden. ;)

MichaelPaul

Vielen Dank für das Interesse und das Angebot dem ich sicherlich bald nachkommen werde. Sobald ich eine funktionstüchtige und halbwegs ansehnliche Beta-Version anbieten kann, werde ich alle die daran interessiert sind darüber informieren und das Modul zu Testzwecken zur Verfügung stellen.

MichaelPaul

#7
Ist es korrekt, dass ein eintreffendes Events lediglich ein einziges mal bzw. nur von einem einzigen notify abgefragt und verarbeitet werden kann?

In meinem konkreten Fall gibt es zwei Notifys die wie folgt definiert worden sind:       
define SMS_Reply   notify SMS_DEVICE:incoming_Received:.* set SMS_DEVICE SMS-respond-Message Okay, your Message was received! 
define SMS_Forward notify SMS_DEVICE:incoming_Received:.* set SMS_DEVICE SMS-send-To-Message 491638888 A incoming Message was received!

Die automatisch generierte NR die in den Internals von SMS_Forward steht ist 89 und die NR die in den Internals von SMS_Reply steht ist 127.

Beim Eintreten des Events SMS_DEVICE:incoming_Received:.* wird nun einzig und allein das notify SMS_Forward mit der NR 89 ausgelöst.

Nachdem das notify SMS_Forward (89) gelöscht worden ist, führt dann ein erneutes Event SMS_DEVICE:incoming_Received:.* dazu, dass das noch verbleibenden SMS_Reply (127) ausgelöst wird.

Bei einem weiteren Versuch habe ich mit den beiden unterschiedlichen Events durchgeführt:
define SMS_Sent   notify SMS_DEVICE:incoming_Sent:.* set SMS_DEVICE SMS-send-Message Your Message was triggered by the Event incoming_Sent! 
define SMS_Received notify SMS_DEVICE:incoming_Received:.* set SMS_DEVICE SMS-send-Message Your Message was triggered by the Event incoming_Received!

Die automatisch generierte NR in den Internals zu SMS_Sent ist 241 und bei SMS_Received 281.
Es wird in diesem Fall auch nur das notify mit der kleineren NR ausgelöst.

Darf ich davon ausgehen, dass dieses NOTIFY - welches aufgrund der NR-Reihenfolge zuerst ausgeführt wird - auch gleichzeitig dafür sorgt, dass kein weiteres NOTIFY ausgeführt werden kann?

Einige weitere Tests haben mich dazu bewogen dies annehmen zu müssen.




MichaelPaul

Hallo nochmal,
sehr gerne würde ich ein Modul zum Empfangen und zum Versenden von SMS-Nachrichten zur Verfügung stellen. Die geschriebene Dokumentation habe ich mir angesehen und auch einige der offiziell freigegebenen und somit vorhandenen Module doch - entschuldigt bitte - musste ich als NEUER feststellen, dass nicht alle vorhandenen offiziellen Module als Referenz-Module tauglich sind. Lob für die vorhandene Dokumentation, da diese eine Vielzahl von Funktionen und Features sehr klar beschreibt doch - und so muss man es einfach sagen - unzureichende Praxisbeispiele liefert. Sehr gerne hätte ich als FHEM-Einsteiger ein einwandfreies Modul zur Verfügung gestellt, jedoch fehlt es aktuell an exemplarischen Beispielen an denen man sich orientieren kann mit dessen Hilfe man ein solches realisieren kann. Dennoch habe ich mich nicht davon abschrecken lassen und habe versucht mein Modul zu realisieren. Es funktioniert und dennoch erhoffe ich das Feedback der Gemeinschaft um konzeptionelle Fehler zu beseitigen und Verbesserungen als auch Erweiterungen in zukünftige Versionen einbauen zu können.
Ich hoffe und bitte um Reaktion

CoolTux

Hallo Michael,

Da liegt daran das es nicht DAS "Referenzmodul" gibt. Wenn User fragen zu bestimmten Funktionen oder besonders deren Vorgängen haben verweise die Entwickler gerne mal auf das ein oder andere ymodul wo es eine ähnliche Funktionsweise bereits gibt. Alles andere ist Entscheidung des Entwicklers.
Es gibt aber eine Developer Doku mit Erklärungen und Beispielen der meisten FHEM Funktionen. Mit daran angebunden ist auch wie das in ein FHEM Konformen Modul gepresst werden sollte. Ne Art Developer API wenn Du so willst.
Ansonsten findest Du als Entwickler auch viele Antworten zu FHEM Funktionen in der fhem.pl.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MichaelPaul

#10
Naja, wie bereits angekündigt - dieses Modul funktioniert!

Und auch die Pflicht-Dokumentation dazu wurde - in englisch - umgesetzt!

Dennoch sehe ich in dem aktuellem Stadium Möglichkeiten der Optimierung und hoffe und bitte weiterhin um - konstruktives Feedback auch gerne direkt an: Fhem.de@myhw.de!

Das Modul trägt aktuell den Namen: 99_SMS2OOL.pm

Grüße,
Michael Paul

CoolTux

Ach so, fast vergessen. Es gibt ein inoffizielles Mentorenprogramm. Einfach mal den ein oder anderen aktiven Developer per PN anschreiben und fragen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

CoolTux

Hallo Michel

Bitte entfernen das aktuelle 99er Modul und benenne es in alles um nur nicht in 99.
Du kannst schauen ob Du Module findest die ähnliches machen wie Deines und dann diese Nummer oder den Bereich nehmen. Pushover zum Beispiel.
Module mit 99 werden immer automatisch beim FHEM Start geladen und verbrauchen somit Ressourcen. Andere Module werden immer erst bei einem Define geladen.


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

MichaelPaul

#13
SMSTOOLS zum Senden und Empfangen in FHEM -> SMS2OOL still alive!

Aufgrund des vorhergehenden Hinweises wurde das Modul - obwohl inhaltlich gleich - nun umbenannt und auch einige Änderungen durchgeführt:
55_SMS2OOL.pm