hallo
zur Erinnerung: bin dabei die Heizungssteuerung von Hrn Busker von
Codevision nach Win_avr zu transferieren und bin mit Hilfe des Forums
auch ein ganzes Stück weitergekommen. So läuft nun das Thema ADC sehr
gut, nachdem ich einen Offset zusätzlich eingebaut habe. Beim Original
sind trotz vorgegebener Bauteile die gemessenen Temperaturen viel zu
hoch (30° statt 20°). Könnte man mit Trimmern lösen, ja aber nicht sehr
interessant.
Nun habe ich aber weiterhin Probleme mit dem EEPROM. Ich beschreibe
mittels avr_lib das EEPROM wie folgt
uint16_t MaxKesselTemperatur[3] EEMEM;
unsigned char CheckEEPROMData EEMEM;
#define TAG 0
....
eeprom_write_word(&MaxKesseltemperatur[TAG],750);
eeprom_write_byte(&CheckEEPROMData,1);
....
und lese es zur Darstellung wie folgt ein:
.....
hv=eeprom_read_byte(&CheckEEPROMData);
itoa(hv,c,10);
strcat(c," ");
lcd_puts(c);
while (!eeprom_is_ready()) {;}
hv=eeprom_read_word(&MaxKesselTemperatur[TAG]);
itoa(hv,c,10);
strcat(c," ");
lcd_puts(c);
Ergebnis:
CheckEEPROMData = 1
MaxKesselTemperatur = 238
Hat jemand eine Idee, woran das hängt, dass 1 korrekt bleibt aber 750 zu
238 wird??
Danke im Voraus für die Unterstützung.
Werner
750 binär dargestellt ist 1011101110 Wenn ich nur 8 Bit habe, dann fallen die obersten zwei bits raus... bleibt also 11101110 und das ist 238. Gruss XXX
hi XXX, habe doch mit uint16_t 2 Bytes (16 Bit) vereinbart und schreibe sowohl als auch lese mit write_word und read_word jeweils 2 Byte. danke Werner
Werner Freytag schrieb: > hi XXX, > > habe doch mit uint16_t 2 Bytes (16 Bit) vereinbart und schreibe sowohl > als auch lese mit write_word und read_word jeweils 2 Byte. woran siehst du das?
1 | hv = eeprom_read_byte(&CheckEEPROMData); |
2 | ....
|
3 | hv = eeprom_read_word(&MaxKesselTemperatur[TAG]); |
Was hat hv für einen Datentyp? (Womit man wieder einmal sieht, dass einigermassen sprechende Variablennamen absolut kein Luxus sind. Das bischen mehr Tipparbeit spart man durch verminderte Fehlersuche 10-fach wieder ein)
Hallo Werner, ich wollte mit meinem Kommentar nicht direkt einen Fehler in deinem Sourcecode aufzeigen. Mir ist nur aufgefallen, dass aus 750 schnell 238 werden wenn die die beiden oberen Bits wegfallen. Ist es evtl. ein Problem mit dem zweiten Aufruf von "itoa(hv,c,10)"? Wie ist den hv deklariert? Gruss XXX
merci XXX, habe einen weiteren Test gemacht und stelle fest, dass ich hv falsch deklariert habe. Im Programm ist es als char deklariert. Nehme ich int, dann funktioniert auch ITOA. Bist Du fit mit dem Schreiben ins EEPROM? Habe mal einen Ausdruck des EEPROM Inhalts mit PonyProg gemacht und stelle Sonderbares fest. Die eingegebnen Werte sind nicht der Reihe nach im EEPROM (so wie eingegeben), sondern immer in Gruppen zusammen. Aber auch bei den Gruppen (zB alle Eingaben 300 oder -xxx) ist keine Logik für mich erkennbar. Neg Werte stehen mitten drin, die anderen Werten gehen von der Größe rauf und runter. Da ist es mir unklar, wo die zugehörigen Adressen stehen, im EEPROM jedenfalls scheinbar nicht. Hast Du eine Ahnung? mfG Werner
Werner Freytag schrieb: > merci XXX, > > habe einen weiteren Test gemacht und stelle fest, dass ich hv falsch > deklariert habe. Im Programm ist es als char deklariert. Autsch. Grundregel: einen 'char' nimmst du ausschliesslich und nur dann, wenn du es tatsächlich mit einem Character (im Sinne von Text) zu tun hast. Wenn das was du hast, im weitesten Sinne einfach nur ein Byte ist, dann nimmst du immer 'unsigned char' oder besser gleich uint8_t. Byte == unsigned char Character == char Hier definiert also der Verwendungszweck, bzw. das Wissen darüber was der Inhalt der Speicherstelle sein soll, ob du char oder unsigned char benutzt. Tust du das nicht, bzw. bist du hier nachlässig, kannst du ganz böse auf die Schnautze fallen! > Nehme ich int, > dann funktioniert auch ITOA. Das hat sowieso immer funktioniert. Aber ... hv = eeprom_read_word(&MaxKesselTemperatur[TAG]); Da wird sich die Zuweisung schwer tun, ein ganzes Word (also 2 Bytes) in eine Variable zu pfriemeln, die nur 1 Byte aufnehmen kann. > der Größe rauf und runter. Da ist es mir unklar, wo die zugehörigen > Adressen stehen, im EEPROM jedenfalls scheinbar nicht. Die verwaltet der Compiler/Linker uint16_t MaxKesselTemperatur[3] EEMEM; unsigned char CheckEEPROMData EEMEM; Durch das EEMEM teilst du mit, dass du die Variable gerne im EEPROM haben möchtest. Aber wo genau im EEPROM, das teilen sich Compiler/Linker ein. Du streitest dich ja mit deinem Compiler auch nicht darüber, wo er die Variable i im Speicher anlegt, wenn du ein i brauchst. Das wichtigste ist doch, dass du von derselben EEPROM Adresse liest auf die du auch geschrieben hast, wenn du dich auf &CheckEEPROMData beziehst.
Hallo Werner, sorry, ich bin nicht fit was das Schreiben ins EEPROM angeht. Generell sind meine Kenntnisse was C-Programmierung und Mikrocontroller angeht eher gering. Aber andere können Dir hier sicherliche weiterhelfen. Ich lese auf jeden Fall interessiert mit. Viel Erfolg... Gruss XXX
Hi, wie weit ist denn die umstellung auf winavr gediehen? ich entwickele auch gerade die software weiter und will den sourcecode auch auf einen anderen compiler umstellen.
Hi Martin das Programm ist längst fertig und arbeitet an einer Viessmann-Heizung. Allerdings läuft es bei mir noch ohne die UART Kommunikation mit dem PC. Das Programm ist nun in WIN-AVR compilierbar (also einfach mit Studio4 von ATMEL. Zusätzlich habe ich auch noch mehr kommentiert, so dass es gut verstehbar ist. Im Programm habe ich die Spezifika für die Fußbodenheizung eingebaut, wie Pumpensteuerung der Umwälzpumpe des Heizkreises und Fernbedienung mittels eines Potentiometers -Absenken und Anheben der Kennlinie-). Schau Dir das mal an, es funktioniert prima. Zur Zeit bin ich dabei die Sommer-/Winterzeit Umschaltung zu programmieren. Das dauert noch ein bisschen, weil ich kaum Zeit investieren kann. mfG frewer
hab auch einiges vor: Ziele: 1. optimierung des verbrauchs 2. bedienungskomfort 3. sicherheit, besonders bei abwesenheit todo: 1. verstehen und kommentieren des quelltextes (50%) 2. anpassung der menüstruktur an ein 20x4 display (25%) 3. alarm bei kessel über oder unter-temperatur (0%) 4. anschluss eines handys an die serielle schnittstelle zur alarmierung bei störung (0%) (zur zeit mit ELV handy-alarm) 5. erfassung und verarbeitung der rücklauf-temp mit einem zusätzlichen kty81 (100%) 6. erfassung diverser raumtemperaturen und beachtung bei der regelung durch eine kette von Ds1820 (10%) 7. abgesetzte anzeige (event. auch steuerung) über funk (0%) 8. alarm bei pellets-stand zu niedrig (oder öl) (0%) 9. alarm bei druckverlust im heizkreislauf (0%) 10. alarm bei rauch (25%) (zur zeit mit ELV handy-alarm) 11. anpassung des quellcodes an einen freien compiler 12. fehler in der verbrauchsstatistik beheben hast du interesse an informationsaustausch? ist dein modifizierter code public? gruss martin
Hallo Martin, na klar bin ich interessiert am Infoaustausch. Habe versucht das Programm an meine letzte Antwort anzuhängen, bin aber mit dem Thema Freigabe von Programmen im Netz nicht so fit. Public ist für mich nicht klar. Du kannst es gerne benutzen, wobei zu beachten ist, dass ja Busse und Busker das Original entwickelt haben. Ich habe nur umgeschrieben und ergänzt. Ob das als public bezeichnet werden kann ist mir nicht bekannt. mfG frewer
mit public meinte ich das du deine änderungen nicht geheim halten willst. der autor hat ja in seinem forum angeboten eine rubrik für angepasste versionen seiner software zu machen, werde ihn mal darauf ansprechen. kannst mir an mpeg42 ät gmx.de schicken
ich kämpfe zur zeit mit dem 1wire bus. so bald ich die sensoren abfrage kommt das ganze timing durcheinander und die uhr stimmt nicht mehr. die pdu-konvertierung ist auch noch ein stück arbeit. mal sehen was ich deinem code für anregungen entnehmen kann... ist übrigens angekommen.
Hi Martin, in einem separaten Programm habe ich den 1-wire Bus prima zum Laufen gekriegt. Allerdings handelt es sich dort um einen ATMEL 89C4051 bzw AT89S51 (meinem Standard-Testboard mit SPI). Hatte zwar einige Zeit gebraucht (Assembler), um den ganzen Kram zu kapieren aber endlich funktionierte es. Dann habe ich mir ein TempMessgerät gebaut, das mehrere (zunächst mal 2) DS abfragen kann. Es ist meine TempStandard, weil ja die Gekauften alles immer etwas Anderes anzeigen. mfG frewer
übrigens, wenn Du Timingprobleme hast, dann ist das vielleicht auch mein Problem bei der Übertragung der Daten an den PC mittels dem UART. Obwohl ich genau nach der Prozedur von Fleury (dessen Dateien ich auch verwende) vorgegangen bin, konnte ich bisher nichts auf dem PC empfangen. Offenbar klappt ja das bei Dir oder? mfG frewer
Hi,
auch ich habe vor meine Heizung einwenig zu optimieren, doch leider ist
der Eingriff der Buss/Busker-Lösung einwenig zu "heavy" für meine
relativ neue Anlage (BJ2005; Vitodens 333).
Daher habe mir folgende Überelgt (Idee/Anregung)
Der Eingriff in die Analge erfolgt über den Aussentemp.-Fühler. Hier ein
NTC zu Erfassung der Aussen.-Temp. angeschlossen. Die Kennlinie muss
einmal Augenommen werden, dieses sollte relativ einfach gehen, da die
gemessene Temp. im Info-Menü angezeigt wird. Eine Mikrocontrollerplatine
misst nun die Aussentemp. und bekommt via Funk-Innenraummessstellen die
Raum-Isttemp und Soll-Temp geliefert ggf. wird via Funk noch die Vor-
und Rücklauftemp. dem Modul geliefert. Aus den dann vorhandenen
Temperaturwerten :
- Aussentemp.
- Innen SOLL-Temp
- Innen IST-Temp (ggf. mehrere!)
- Vorlauf und Rücklauftemp
wird dann eine "sinnvolle" Steuerspannung (analoger Temp-Wert) an die
Heizung
geliefert. Über diesen kann die Heizung dann quasi voll geregelt werden.
Wie bereits erwähnt, es muss kein Eingriff in das Gerät erfolgen !
Hallo Visitor, na klar geht das! Aber mir scheint die Verwendung von 5 Messwerten von Temperaturen schwierig mit der Aufgabe der Heizungssteuerung zu vereinbaren zu sein, da ja "nur" der Kessel geregelt wird (es sei denn Du kannst bei Deiner Heizung auch die einzelnen Ziummer regeln - Radiatorheizung-). Ich habe auch lange überlegt, ob ich den Rücklauf mit in die Temperaturmessung mit einbeziehe, dann aber darauf verzichtet, weil mir zunächst kein Mechanismus einfiel, um diese Temperatur zu beeinflussen. Mittlerweile bin ich da weiter und überlege, ob ich mit der Rücklauftemperatur die Umwälzpumpen-Abschaltung steuern soll. Das Abschaltkriterium könnte z.B. die Änderung der Rücklauftemp sein. Es macht ja Sinn, dass man nicht das bereits zur Heizung verwendete "Kaltwasser" umwälzt, denn dann macht man den Heizeffekt eigentlich kaputt und entzieht jetzt dem heizkreislauf Wärme. Dazu muss ich aber erst mal untersuchen, wie sich die Änderung verhält. Bisher schalte ich die Pumpe einfach nach einer gewissen Zeit (15 Min) ab. Den Wert könnte man im Service-Menü noch veränderbar machen (was noch nicht der Fall ist). Hierzu bin ich noch nicht ans programmieren gekommen. Der AD-Wandler und Programmspeicher sind ja beim ATMEGA32 ausreichend vorhanden, so dass das kein Problem sein sollte. mfG frewer
die differenz zwischen vor und rücklauf ist ein indiz für den verbrach des hauses. wenn die differenz gross ist erhöhe ich die kesseltemperatur um 1/4 der diff.
Mit der Definition der Differenz bin ich nicht ganz einverstanden. Im wesentlichen hängt die Differenz von der Verlegung und der Dimensionierung der Heizrohre ab. Ich komme auch mit viel Anstrengung bei mir nicht über eine Rücklauftemperatur von 22-24 Grad hinaus, füttere meine Heizrohre allerdings auch mit maximal 40 Grad im Vorlauf - wenn es richtig kalt ist-. Wichtig ist ja bei der Fußbodenheizung, dass dem Benutzer die Beine nicht wehtun. Ich werde mal Versuche machen über die Veränderungen der Rücklauftemperatur, wenn es etwas kälter ist. Zur Zeit läuft die heizung zu selten. mfG frewer
bei mir läuft der vorlauf zwischen 40 und 65 grad. der rücklauf bei kaltem haus liegt so bei vorlauf-20. bei warmem haus bei vorlauf -5. voraussetzung ist natürlich eine kopplung von vor und rücklauf am kessel. dort läuft das wärme wasser im kreis wenn keins von der pumpe abgezogen werden kann.
Hallo Martin, sprechen wir wirklich von einer Fußbodenheizung? Ein Rücklauf mit bis zu 60 Grad heißt doch, dass die Füsse kochen, wenn man über den Boden geht. Also ich kann das kaum glauben. Solche Temperaturen gibt es m.E. nur bei Hochtemperaturheizungen, die über Radiatoren die Wärme abgeben. Dann macht natürlich auch die Steuerung von jedem Raum Sinn ebenso wie die Steuerung unter Verwendung des Rücklaufs. mfG frewer
Soweit ich weiß, darf eine Fußbodenheizung nicht mehr als 45° Vorlauftemperatur haben. Wir speisen unseren Heizkreis jedenfalls mit maximal 45° (bei -20° Außentemperatur). Dabei haben wir hauptsächlich Wandheizung und nur im Bad und Küche (Fliesenboden) eine Fußbodenheizung. 65° ist nur für (alte) Heizkörpersysteme gedacht. Im Normalfall wird eine Heizung so dimensioniert, dass man eine Spreizung (Differenz zwischen Vor- und Rücklauf) von ca 5°C hat. Gut, zum Aufheizen eines kalten Hauses kann es schon mal mehr sein.
ja klar hab ich keine fussbodenheizung, sondern normale heizkörper. es geht ja auch um die heizungssteuerung im allgemeinen. der thread heisst ja auch "Heizungssteuerung mit ATMEGA 32" :-)
Hallo, nun ich habe ja das Thema hier im Forum begonnen und klargestellt, dass meine Änderungen am Programm insbesondere deshalb notwendig wurden, weil ich eine Fu´ßbodenheizung betreibe und keine Radiatorenhzg. M.E. ist für eine Radiatorenhzg der Ansatz von Busse/Busker im Original ok. Hat jemand mal festgestellt, was ich mit der UART-Programmierung falsch mache? Ich bekomme in keinem Terminalprogramm Kontakt. Wenn ich dann ein eigenes Programm mit den gleichen Befehlen erstelle funktioniert dieses Programm dann normal. Gibt es da ggf. ein Problem mit dem Interrupt oder gar mit den Timern?? mfG frewer
das ist bei mir das nächste. sms versenden bei kessel über-unter temp. scheint ganz einfach. morgen wissen wir mehr :-)
Hi Martin, warte noch immer auf Deine Lösung des Problem der Kommunikation über den UART des ATMEGA32. Ich habe nunmehr die Routinen mehrfach hin und her untersucht und mit den Eingaben von hrn Fleury verglichen, doch kann ich keinen Fehler feststellen. Ich bin sehr an einer Lösung interessiert, da die Kommunikation natürlich das i-Tüpfelchen wäre. Habe noch ein bisschen am Programm optimiert. Die Verschiebung der Kennlinie mittels Potentiometer funktioniert einwandfrei, ebenso die Steuerung der Umwälzpumpe. Jetzt fehlt neben der Kommunikation nur noch die automatische Umschaltung Sommer-/Winterzeit, dann ist alles perfekt. Im übrigen habe ich noch immer ein Verständnisproblem mit der Zuordnung der 0x4000 zu den Werktagen und wenn ich so im Programm rumschaue, dann wird die Konstante WERKTAG auch stets durch 1440 dividiert also warum nicht gleich die Konstante mit 0x4000/1440 ??? Bin auf Hilfe bei meinem Fehler gespannt. mfG frewer
Hallo Leute, ist der Thread noch aktiv? Habe eine alte Heizungssteuerung auf z80 basis, die muss mal renoviert werden- hatte da an ATMega gedacht- hab heute 2 Heizkreise- aussentemperatur gesteuert, Pumpenstuerung-nachlauf, sommerzeit, kty-fühler. wie weit seit ihr mit der SW? gruß Horst
Hallo Horst, meine Heizung mit dem ATMEGA32 läuft soweit mit Ausnahme der Kommunikation über USART und RS232. Da habe ich bisher noch keine Arbeit investiert. Ansonsten ist alles "perfekt" für die Fussbodenheizung umgeschrieben und läuft mit WIN-AVR also Änderungen können leicht im Studio4 gemacht werden. bDie version von Hrn Busker war für Codevision geschrieben und leider so groß, dass man den kostenlosen Compiler nicht nutzen konnte zum Compilieren. Deshalb hatte ich das programm umgeschrieben, teilweise erleichtert und an die Bedürfnisse einer Fußbodenheizung angepasst (zB Pumpensteuerung, uam). Die hardware habe ich dem Vorschlag Busker nachgebaut, ist dem Grunde nach eigentlich simpel. mfG frewer
Hallo Frewer, kannst du mir deine SW und den HW-Vorschlag senden- hab vor das entweder über AVR-Net-IO oder eine andere ähnliche HW zu machen- ggf Erweiterung EIB kommunikation- hab Freebus/EIB für meine Rollladen am laufen. Gruß Horst
Hallo Horst, gib mir Deine e-mail Adresse und ich schicke Dir die Datensätze. mfG frewer
hi, hab nach dem winter das projekt auf pause gesetzt. jetzt hab ich meinen letzten windows-pc durch OSX ersetzt und will das projekt (AVR studio) jetzt unter OSX oder ggf einem virtuellen windows weiter betreiben. suche jetzt noch einen usb-atmega programmer der auch mit osx oder einem virtuellen windows funktioniert. in 1-2 wochen will ich das projekt fortsetzen...
Hallo frewer, Ich habe interessiert deine Beiträge gelesen und bin am überlegen, mich auch an eine Umrüstung ranzuwagen - wäre sehr nett, wenn du auch mir deine Datensätze zu Verfügung stellen könntest! Rüste gerade von Ölbrenner auf Gasbrenner um und würde in dem Zuge auch gern die Steuerung "überholen"... Vielen Dank im Vorraus!!! Viele Grüße Leon leon0381@gmx.net
fehler in meiner letzten nachricht: es muss codevisionAVR nicht avr studio heissen. der originalcode ist in codevisionAVR2 format. ich würde ihn gerne in was freies umschreiben, aber kam noch nicht dazu. mein usb programmer ist heute gekommen (DIAMEX) und das nokia 6310i das als eines der wenigen sms versand ohne pdu-mode kann. jetzt fehlt noch das datenkabel, aber werde am wochenende wieder meine entwicklungsumgebung aufbauen. noch kurz zum stand meiner entwicklung: hab die tastatur von 5 auf 10 tasten erweitert. 3. temp-sensor für die rücklauf-temp angeschlossen. display auf 4x20 erweitert zählung der brenner-starts (bei pellets wichtig) reduzierung der brenner-starts durch größere hysterese (brennerschutz) todo: sms alarm und info über rs232 und handy zusätzliche alarm-eingänge für sms (pellets-lager überwachung) mehr sensoren über 1-wire bus (hatte timing-probleme) internet-anbindung (wenn mal alles andere fertig ist) den aktuellen quellcode bekommt ihr in kürze
anbei die aktuelle source (main.c) meiner heizungssteuerung. und hier noch eine kleine linksammlung zum thema sms versenden mit mikrocontrollern: http://www.mikrocontroller.net/articles/Versenden_von_SMS_mittels_Mobiltelefon http://www.developershome.com/sms/howToSendSMSFromPC.asp http://mschrod.de/Elektronik/AVR/Projekte/HandyS45/SMS_Versand.html http://www.embedtronics.com/nokia/fbus.html http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=60099&start=0 http://home.arcor.de/RoBue/AVR-PC-Ctrl/ http://www.elektor.com/magazines/2008/november/remote-control-by-mobile-phone.704109.lynkx?tab=3 http://www.ulrichradig.de/home/index.php/avr/avr_handy http://gandalf.arubi.uni-kl.de/avr_projects/eversmith/index.html http://www.nobbi.com/sms_pdu.html
Hallo Martin, hast ja ganz schön gewütet. Mich interessieren 2 Dinge: 1. das ist ja nicht Codevision aber auch nicht avr-Gcc (in Studio4) - mir sind beim raschen Lesen die Interrupt-Routinen aufgefallen, die ich von avr-GCC anders kenne 2. funktioniert Deine Kommunikation über den USART? Wenn ja, dann übernehme ich Deine Zeilen ganz einfach. Ich habe nämlich die Library von Fleury eingebunden aber ohne Erfolg. mfG frewer
code ist codevisionavr 2.03 format serielle routinen sind noch nicht getestet. warte auf mein datenkabel zum nokia 6310
meine entwicklungsumgebung steht wieder, diesmal auf dem mac. mac mit osx 10.6.8 oracle virtual box mit windows XP codevisionAVR 2.0.3 DIAMEX USB programmer ponyprog musste leider raus, weil es direkt mit der hardware spricht. heute sollte das nokia datenkabel kommen und dann gehts los mit sms und serial programming.
kabel ist da, komme aber doch nicht weiter. hab jetzt gelernt das die kommunikation bei nokia über den f-bus erst dann funktioniert wenn das handy vorher über den m-bus aktiviert wird. die einfachen datenkabel können das nicht. das dlr-3 hat einen pic drin der die kommunikation aktiviert, meines aber nicht. hab jetzt 3 möglichkeiten: 1. dlr-3 kaufen 14,- 2. doch mein s45 nehmen und mit pdu rum schlagen 3. billiges siemens kaufen das text-mode kann 10-20,- grrrrrr.
hab ein S55 bestellt, den pdu-converter von ulrich radig hab ich mir trotzdem angeschaut, aber den code noch nicht ganz verstanden. muss wohl noch einen c-aufbaukurs belegen.
will mich mal wieder melden. bin jetzt wieder dran. folgendes steht als nächstes an: 1. UART kommunikation testen 2. SMS versand mit PDU konverter 3. temp-sensoren auf 1-wire umstellen, wegen genauigkeit. hab auch mal kurz überlegt ob eine umstellung auf arduino sinn macht, was denkt ihr?
Hallo Martin, was ist denn ein "arduino"? Wie weit sind Deine Untersuchungen zum Thema USART benutzen. Also bei mir hat die Heizung nun den bisherigen Winter zur Zufriedenheit gearbeitet. Ein bisschen schwierig ist bei der Fußbodenheizung halt noch die Funktion in der Temperaturübergangsphase. Da muss ich mit dem Potentiometer die Regelgerade verschieben. Ich bin aber paralle am Überlegen, ob ich nicht für die Temperaturen von +10°C bis +18°C eine zweite Regelgerade einführe, die eine andere Steigung hat. So etwas hat meine alte analoge Steuerung (halt automatisch). mfG frewer
Wollte den Thread nochmal aufwärmen. Hab die Handy-Anbindung nie ans laufen bekommen. Die Low-Cost Regelung hat mir lange treue Dienste geleistet. Jetzt habe ich begonnen einen Nachfolger zu entwickeln mit einem ESP32. Bastelt noch jemand an der originalen Regelung oder hat Interesse an Informationen zu dem Nachfolger?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.