Hallo ins Forum, ein SMS-Überwachungs- und Schaltmodul (von elv: Best.-Nr. 103896) gibt nur fest verankerte SMS-Texte heraus (z.B. SMS empfangen Ausgang 1 ein). Ob es sich hierbei um den eigentlich versendeten Text handelt oder ob dieser Text im Controller generiert wird, nachdem eine Schalt-SMS einging, ist bis jetzt noch nicht klar. Ich habe das Modul noch nicht zum Testen vorliegen. Man kann mit diesen Modulen sowohl einen Relaisausgang schalten als auch einen Masseeingang überwachen ( jeweils 2 davon). Ich möchte nun erreichen, dass zwei dieser Module miteinander in Austauch treten. Lt. Bedienungsanleitung akzeptiert das Modul jedoch nur eine eingehende SMS in einer bestimmten Parameterisierung (z.B. #0000#201#1#001#; damit würde dann in diesem Fall der Schaltausgang 1 für eine Sekunde auf ON gesetzt). Eine Kommunikation zweier solcher Module untereinander war wohl nicht vorgesehen. Es gibt auch kein Menü, welches ein Anlegen spezieller Texte für eine SMS ermöglicht. Man kann das Modul bislang nur mit einer Handy-SMS in o.g. Format ansprechen. Es handelt sich um eine SMD-Platine mit einem ATmega329V-8MU_MLF64M1. Gibt es die grundsätzliche Möglichkeit, das interne Microcontrollerprogramm abzuändern, so dass man einen Menüpunkt schaffen kann, der das Anlegen frei definierbarer SMS-Texte gestattet? Falls ja, wie ist dabei vorzugehen bzw. hat das schon einmal jemand versucht? Grüße
Klar...bau das Ding auseiander, erstelle einen Schaltplan und schreib dir dein eigenes Programm. Danach über ISP programmieren und fertig.. Den vorhandenen Code kann man zwar auslesen wenn das Lockbit nicht gesetzt ist allerdings bringt der meistens nicht viel.
TestX schrieb: > Den vorhandenen Code kann man zwar auslesen wenn das Lockbit nicht > gesetzt ist ... Da würde ich bei ELV aber nicht mit rechnen.
Dazu müsste es allerdings eine Schnittstelle geben, die ich nicht ersehen kann. Möglicherweise wurde der ATmega vor der Montage extern programmiert? Also ist das Thema eigentlich schon durch.
Musst halt einen isp adapter an die pins klemmen...wenn das schon ein problem wird nimm lieber gleich zwei arduinos mit gsm shield etc....
Guck doch mal im Datenblatt, welche Pins am µC für ISP und JTAG sind... Mit einer sehr hohen Wahrscheinlichkeit, findest du auf den Leitungen Testpunkte über die der µC mal programmiert wurde. Eine echten Stecker baut fast keiner in seine Produkte ein - ist einfach zu teuer...
Es gibt auch dokumentierte Module. Und diverse mehr oder weniger verständliche Tutorials. Schneller kommst du zum Ziel, wenn du dir zunächst ein SMS-Modul und eine ATmega-Platine für Hobbybastler zulegst. Die Beispiele durcharbeitest und erst danach, wie von TestX beschrieben, dein Modul umprogrammierst. Die Firma Adafruit z.B. liefert Module mit brauchbaren Lehrbeispielen. Kannst aber auch umgekehrt im Netz nach einem Tutorial suchen und die verwendeten Module kaufen.
Die für SMS-Empfang benutzten AT-Kommandos werden von (quasi) allen Modulen unterstützt, man muss eben nur sehen, was man als Init-Sequenz hinschicken muss. Bei manchen muss man den SMS-Zeichensatz umstellen, bei anderen AT+CSMP einstellen, etc... Für das Neoway M590 lautet die Init-Sequenz z.b. so: 1) Auf +PBREADY (oder fixe Zeit) warten... AT+ENPWRSAVE=0 AT+CMGF=1 AT+CSMP=17,167,0,0 AT+CNMI=2,2,0,0,0 AT+CSCS="GSM" Und ab dann ist es genau gleich - jede SMS kommt so an: +CMT: "+4368112345678",,"17/01/01,00:00:00+08" Zeile 1 Zeile 2 Einzige Schwierigkeit hierbei ist es, das ganze sauber zu implementieren - was ich im Moment grade in C mache - und zwar so, dass es egal ist, ob ein Leerzeichen/Newline mehr oder weniger bzw. irgendwas anderes dazwischen vom GSM-Modem kommt und dass das ganze Interrupt-gesteuert abläuft und kein Zeichen verschluckt wird. Bisher sind es bei mir ca. 500-600 Zeilen C-Code, der u.a. eine State-Machine, einen Ringpuffer und einen flexiblen AT-Parser (ohne sscanf-Bloat) und ein "intelligenten" Resetlogik implementiert und ich bin immer noch beim optimieren... https://i.imgur.com/tm0Oqt2.png Wenn es aber nur um relativ simple Kommandos, ein einziges GSM-Modul und fixe Schaltbefehle geht, kannst du dir das relativ schnell wohl mit einem Arduino zusammenfrickeln. Es gibt sogar eine universelle GSM-Library: https://github.com/vshymanskyy/TinyGSM 1) Du findest mal die RX/TX Pins des GSM Moduls und sorgst dafür, dass der ATMEGA nicht mehr mit dem Modul kommuniziert (Reset-Leitung des ATMEGA, falls aktiv/möglich auf Masse oder RX/TX abklemmen) 2) RX/TX/GND an einen USB-TTL-Wandler (FTDI, CP2102, PL2303, ...) und die benötigten Standard-Kommandos (AT+CNMI, AT+CMGF=1, AT+CSCS="GSM", ... +CMT) ausprobieren, daran merkst du, wie das Format ist. 3) Ein Arduino/AVR/Whatever-Programm schreiben und mittels USB-TTL Wandler die Antworten des GSM-Modems simulieren, bis dein Programm richtig reagiert PS: WOW ist das Zeug von ELV teuer... 119 EUR verlangen die für so einen Dreck! Das programmiere ich grad auf einem 50 Cent STM8-Board mit einem 2 EUR GSM-Modul, wobei meine Lösung dann auch Passwörter, Anrufer-Erkennung und viel mehr können wird. Ein HD44780-Display dazubauen sollte auch keine Schwierigkeit sein, wenn man's unbedingt braucht... Gesamtkosten (exkl. "Arbeitszeit") ~ 3-5 EUR. Mit Display und Relais < 10 EUR. Sollte es fertigwerden und sauber laufen, kommt's als Opensource-Projekt rein.
:
Bearbeitet durch User
TU S. schrieb: > PS: WOW ist das Zeug von ELV teuer... 119 EUR verlangen die für so > einen Dreck! Ist dann aber auch so ziemlich idiotensicher. Es gibt Leute, die haben einfach Spaß am Basteln. Die wollen nicht genau wissen, wie man was selber entwickelt. Ist so wie malen nach Zahlen. Nur eben mit Lötkolben und bunten Bauteilen. Genauso hatte bei mir das Interesse an der Elektronik begonnen. Ich hatte mich als Kind total gefreut, wenn ich bei meinem Vater auf Arbeit paar Bauteile auf eine Platine löten durfte. Da hat man sich wie ein Held gefühlt. Also ich würde solche Anbieter wie ELV jetzt nicht gleich als Abzocker bezeichnen. Eher als "Erlebnisdienstleister" :-) Manche müssen auf den Mont Everest steigen. Wie bekloppt ist das denn erst?
> Die wollen nicht genau > wissen, wie man was selber entwickelt. Trifft das nicht mehr oder weniger auf uns alle zu? Ich habe auch keinen blassen Schimmer, wie die CPU unter der Tastatur meines Notebooks ihre Befehle Cached und Pipelined. Ich werde wahrscheinlich auch nie in meinem leben eine USB Schnittstelle selber bauen können, aber ich benutze sie in fast jedem Experiment.
Stefan U. schrieb: > Trifft das nicht mehr oder weniger auf uns alle zu? Ich habe auch keinen > blassen Schimmer, wie die CPU unter der Tastatur meines Notebooks ihre > Befehle Cached und Pipelined. > > Ich werde wahrscheinlich auch nie in meinem leben eine USB Schnittstelle > selber bauen können, aber ich benutze sie in fast jedem Experiment. Ja, da hast du recht. Mir ist es auch egal, wie eine Library programmiert wurde. Hauptsache, sie funktioniert.
Hi Alexander L. schrieb: > a, da hast du recht. Mir ist es auch egal, wie eine Library > programmiert wurde. Hauptsache, sie funktioniert. Da hinkt Es aber etwas - bei dem USB-Gelump können wir uns recht sicher sein, daß wir (zumindest ich) Da Nichts dran repariert bekomme. Wenn die soeben eingebundene Library (egal von wo) aber nicht zu 100% macht, was Sie soll, schadet Es nicht, wenn man - zumindest theoretisch - die Funktion reparieren kann. Zwar Beides Elektronik, aber doch ein kleiner Unterschied ;) MfG
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.