Wemos D1, NodeMCU, ESP8266

root2

Zitat von Momo90

müsste wegen des char vergleichs dann nicht schon beim kompilieren ein fehler ausgegeben werden?

Nicht unbedingt, da C recht lax ist, was die Typsicherheit angeht. C ist zwar stark typisiert aber nur schwach überprüft... Da rutscht einiges durch den Compiler, solange der nicht z. B. mit -Wall bei gcc angestoßen wird.

Weiteres Übel kommt, wenn der Vergleich vorher (implizit) gecasted wird. Denn ein ASCII Char '0' ist Dezimal 48... Wobei ein char mit oder ohne Vorzeichen sein und 8 oder mehr bit halten kann. Ist leider nicht so sauber, je nach Maschine auf der der Code laufen soll.

Ggf. kann man das umgehen, wenn man explizit nach int casted (ungetestet): if ( ((int)d >= 0) && ((int)d <= 9) )

ClaudiaF

@root2

Ich dachte char wäre ein signed int?

Auch wenn ich keine Freund dieser '0' <= d UND d <= '9' bin, sollte in diesem Fall das nicht
relativ sicher sein, da ja d auch ein char ist?
Wann denkst Du kann es hier zu Problemen kommen? Wenn x auf einmal undefininert wäre?

Danke
Claudia

root2

Zitat von ClaudiaF

Ich dachte char wäre ein signed int?

Soweit ich weiß, ist für char nichts genau definiert. Er kann, wenn als chardeklariert signed sein, kann aber auch unsigned sein und er kann 8 bit groß sein oder eben größer.

Zitat von ClaudiaF

Wann denkst Du kann es hier zu Problemen kommen? Wenn x auf einmal undefininert wäre?

Weil man (ich) nicht weiß, was der Compiler macht, denn die Arduino C Reference sagt, dass es keine Vergleichsoperationen wie < oder > auf char gibt. Macht er aus beidem ein int? Wenn ja: Wie groß ist der int dann (8 bit oder "so breit wie auf der Hardware geht")? Und welchen Wert hat dann der int, der aus dem char gecasted wird... 0 oder 48?

Vielleicht wäre es besser gleich unsigned char und uint_8 zu verwenden, wenn das möglich ist. Aber selbst da muss man aufpassen, ob man den ASCII Dezimalwert bekommt beim Vergleichen oder den Wert, den der char als Ziffer im Dezimalsystem repräsentiert.

C ist in meinen Augen immer etwas schlecht gelaunt, wenn man Zeichen mit Zahlen vergleicht. Bzw. man muss einfach aufpassen, damit nichts ungewolltes passiert.

ClaudiaF

@root2

Vielen Dank für die Info, da hab ich wohl gleich zwei fehlerhafte Infos behalten.
Ich dachte ein char wäre immer 1 Byte groß und immer ein signed int, heisst also, vorher immer die
Referenz zur genutzten C-Version und zum benutzten compiler lesen.

Merci
Claudia

root2

Gerne

Zitat von ClaudiaF

Ich dachte ein char wäre immer 1 Byte groß und immer ein signed int,

Leider nein. Denn int ist ja abhängig von der Maschine, auf der der Code läuft. Ist also ein "natural" Typ, der so groß sein muss, dass er die Werte INT_MIN und INT_MAX (aus limits.h) halten kann. Und die unterscheiden sich z. B. wenn ich eine 8bit Maschine nehme oder eine 32 bit x86.

In limits.h ist übrigens auch definiert, wie viele bit in einem char sind Gibt wohl einige DSPs, die 16 oder 32 bit in char verpacken.

Ich denke relativ sicher ist man tatsächlich, wenn man unsigned char und uint_8 verwendet.

Momo90

Die von Claudia vorgeschlagenen änderungen

Code

if((d >= '0') && (d <= '9'))


und




                        for (int i = 1; i <= readString.length(); i++) 
                        {
                            char d =readString.charAt(i);
                            if(d >= '0' & d <= '9')
                                serialDataIn += d;
                            // if (d == '&') // [Handle delimiter]
                            // {  
                                rawCodes[counter]=serialDataIn.toInt();
                                serialDataIn = String("");
                                counter = counter + 1;
                            // }
                        }

Alles anzeigen

führen zu dieser seriellen ausgabe

Code

GET /430075015507501550750150075040075040075040075040075040075015507501550750155075040075045075040075040075040075040075040075015507504007504007504507504007504007501550750155075040075015507501550750155
100
0#4#0#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#1#5#5#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#4#5#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#1#5#5#0#7#5#0#1#5#5#0#7#5#0#4#0#0#7#5#0#1#5#5#0#7#5#0#1#5#5#0#7#5#0#1#5#5#0#Sent IR signals
GET /435075015507501550750155075040075040075040075040075040075015507501550750155075040075040075040075040075040075040075040075015507504007504507504007504007504507501550750155075040075015508001500750155
100
0#4#0#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#1#5#5#0#7#5#0#4#0#0#7#5#0#4#5#0#7#5#0#4#0#0#7#5#0#4#0#0#7#5#0#4#5#0#7#5#0#1#5#5#0#7#5#0#1#5#5#0#7#5#0#4#0#0#7#5#0#1#5#5#0#8#0#0#1#5#0#0#7#5#0#1#5#5#0#Sent IR signals

die von root2 empfohlenen änderungen

Code

if ( ((int)d >= 0) && ((int)d <= 9) )


und die änderungen von CLaudia 


                        for (int i = 1; i <= readString.length(); i++) 
                        {
                            char d =readString.charAt(i);
                            if(d >= '0' & d <= '9')
                                serialDataIn += d;
                            // if (d == '&') // [Handle delimiter]
                            // {  
                                rawCodes[counter]=serialDataIn.toInt();
                                serialDataIn = String("");
                                counter = counter + 1;
                            // }
                        }

Alles anzeigen

führen zu dieser ausgabe

Code

GET /435075015507501550750155075040075040075040075040075040075015507501550750155075045075045075045075040075040075040075040075015508004007504008004007504508004007501550750155075040075015507501550750155
100
0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#Sent IR signals

Dennoch bleibt die Led tot...

ClaudiaF

Was meinst Du mit Dennoch bleibt die Led tot... ?

was auffällt ist, das die Ausgabe GET... nicht mit dem was vor Sent IR signals steht übereinstimmt,
es ist zwar in Teilen enthalten aber nur in Teilen.

Cheers
Claudia

Momo90

damit meinte ich dass sie ir led keinerlei signale ausgibt

Momo90

Da ich glaube, dass der ursprüngliche Sketch von hier https://www.riyas.org/2014/03/sendin…o-ethernet.html nicht funktioniert baue ich das ganze neu.

Ich hab da auch schon eine idee, die zwar nicht besonders schön ist aber funktionieren sollte. Eigentlich fehlt mir nur noch ein schritt, den ich aber nicht hinbekomme. Dabei muss ich aber auf die RAW codes verzichten, da es an deren übertragung hapert. Was bislang ohne Probleme funktioniert ist das übermitteln von Code, bit und Codierungsart des IR signals, sofern ich die als string in den sketch eingebe. Diese Daten habe ich zuvor mittels dem https://github.com/markszabo/IRre…RrecvDumpV2.ino sketch ausgelesen. Das ist aber natürlich nicht Sinn der Aktion. Daher habe ich mir gedacht dass ich die IRrecvDumpV2.ino in meinen sketch einbaue und das was dabei als Code, Bit und Codierungsart rauskommt als Variable (String) an den anderen ESP via url aufruf übergebe.

Und jetzt das Problem:

Die IRrecvDumpV2.ino gibt die Infos die ich brauche via Serial.print(resultToHumanReadableBasic(&results)) (Zeile 186 bis 202) an den seriellen monitor aus. Da kommt dann sowas raus

Code

Timestamp : 000056.246
Encoding  : SAMSUNG
Code      : E0E020DF (32 bits)
Library   : v2.3.2


Raw Timing[67]:
   +  4538, -  4428,    +   622, -  1624,    +   616, -  1630,    +   620, -  1630, 
   +   618, -   512,    +   618, -   512,    +   616, -   512,    +   616, -   512, 
   +   616, -   512,    +   618, -  1628,    +   594, -  1652,    +   622, -  1628, 
   +   616, -   512,    +   616, -   512,    +   616, -   512,    +   616, -   512, 
   +   616, -   512,    +   616, -   512,    +   594, -   538,    +   618, -  1628, 
   +   616, -   512,    +   618, -   512,    +   618, -   512,    +   616, -   512, 
   +   616, -   512,    +   616, -  1630,    +   594, -  1652,    +   620, -   512, 
   +   616, -  1630,    +   616, -  1628,    +   616, -  1630,    +   594, -  1652, 
   +   620, -  1630,    +   616


uint16_t rawData[67] = {4538, 4428,  622, 1624,  616, 1630,  620, 1630,  618, 512,  618, 512,  616, 512,  616, 512,  616, 512,  618, 1628,  594, 1652,  622, 1628,  616, 512,  616, 512,  616, 512,  616, 512,  616, 512,  616, 512,  594, 538,  618, 1628,  616, 512,  618, 512,  618, 512,  616, 512,  616, 512,  616, 1630,  594, 1652,  620, 512,  616, 1630,  616, 1628,  616, 1630,  594, 1652,  620, 1630,  616};  // SAMSUNG E0E020DF
uint32_t address = 0x7;
uint32_t command = 0x4;
uint64_t data = 0xE0E020DF;

Alles anzeigen

Für mich relevant ist nur Encoding, Code und BIts (das gibt die Zeile 186 des codes der IRrecvDumpV2.ino aus). Ich komme es aber ums verrecken nicht drauf (auch nicht nach lesen der https://github.com/markszabo/IRre…src/IRutils.cpp Zeilen 290ff), wie ich die serielle ausgabe Encoding, code und bits als String in meinen sketch als variable übernehmen kann, da ich die Library nicht so ganz kapiere.

daher bitte @ClaudiaF und @root2: Konnt ihr mir helfen wo ich weiter suchen muss oder wie der code lauten muss damit ich die serielle ausgabe von Encoding, code und bits als String in meinen sketch als variable übernehmen kann?

ClaudiaF

Ich bin momentan leider Land unter ... ich hoffe ich kann mir das Anfang nächster Woche mal anschauen.
Aber gib doch bitte Bescheid wenn Du vorher schon eine Lösung gefunden haben solltest.

Cheers
Claudia

root2

Zitat von Momo90

wie ich die serielle ausgabe Encoding, code und bits als String in meinen sketch als variable übernehmen kann

Wenn Du ein results Objekt hast kannst Du vermutlich (ungetestet) so auf die Felder zugreifen...

Encoding:

C

String encoding = typeToString(results->decode_type, results->repeat);

Code:

C

String code = "";


if (hasACState(results->decode_type))
{
#if DECODE_AC
  for (uint16_t i = 0; results->bits > i * 8; i++)
  {
    if (results->state[i] < 0x10)  code += "0";  // Zero pad
    code += uint64ToString(results->state[i], 16);
  }
#endif  // DECODE_AC
}
else
{
  code += uint64ToString(results->value, 16);
}

Alles anzeigen

Bits:

C

String bits = uint64ToString(results->bits);

Bitte mal ausprobieren und Rückmeldung geben.

Momo90

Ah! Verstehe.

Funktioniert!

Danke!!

don

Bitte noch, wenn fertig, mehr Details.
Habe da auch Interesse.

Und gerade etwas interessantes gefunden
https://www.cron.dk/esp8266-on-batteries-for-years-part-1/

Momo90

Zitat von don

Bitte noch, wenn fertig, mehr Details.
Habe da auch Interesse.

Hab übers Wochenende ein bischen an den Sketches gebastelt und getestet. Wobei ich auch bei diesen Sketches eigentlich nur welche aus dem Web genommen habe, diese kombiniert habe und minimal adaptiert habe. Meine Eigenleistung ist daher eher berschränkt gewesen

Nach meinen Testst funktioniert das ganze tatsächlich. AC Codes konnte ich aber nicht testen, da ich keine AC Fernbedienung zur Verfügung habe. Derzeit können auch keine RAW Signale übermittelt werden, sondern nur Signale deren Protokoll die irremoteESP8266 library kennt (NEC, Sony, Samsung, RC5..) was aber ohnehin die meisten sein sollten. Grundsätzlich sollte es auch möglich sein RAW signale zu übertragen. Dazu müssen aber die Sketches adaptiert werden, was einiges an Hirnarbeit vorraussetzt (Übertragung eines uint16_t arrays als String an den IR Sender ESP und umwandlung dieses Strings am IR Sender ESP wieder in ein uint16_t array).

Bei bedarf lade ich die Sketches gerne hoch. Die Sketches kann man sicher noch sehr verbessern bzw. diese verkürzen..

Danke nochmal an root2 und claudiaF!!

don

Zitat von Momo90

Bei bedarf lade ich die Sketches gerne hoch. Die Sketches kann man sicher noch sehr verbessern bzw. diese verkürzen..

Auf jeden Fall her damit. Gerne auch kurze Bebilderung etc zu den Modulen.

Momo90

Hier mal die Codes. Hinweise habe ich direkt in die Codes gepackt.

Und nochmal: meine Leistung ist bei diesen Codes sehr beschränkt gewesen (zusammenfügung diverser Codes aus dem Netz). Vieles kann man bei den Codes auch noch erheblich kürzen, da einiges nur zum Debuggen diente.
Die IR Sender WLAN konfiguration erfolgt über die WiFiManager Library. Muss grundsätzlich nicht sein, war aber zu faul diese möglichkeit aus dem original Sketch zu entfernen.

Fotos der Module habe ich leider nicht dabei, die kann ich aber nachliefern. Die Schaltung ist aber eh sehr einfach (link in den sketches). Ich habe kleine breakout boards gelötet wo alle bauteile drauf sind. Die Boards sind kleiner als die Nodemcus und werden auf die nodemcus gesteckt. Dadurch werden die Nodemcus nur minimal höher (wenn ich mich richtig erinnere ist ein Nodemcu mit aufgestecktem modul etwa 2 cm hoch). Die dinger sind also relativ handlich

Der IR Empfänger:
https://pastebin.com/u2ygHVPn

Der IR Sender
https://pastebin.com/8RaSUiqE

Bitte steinigt mich nicht für eventuelle Blödheiten in den sketches. Ich bin damit ziemlich unerfahren

root2

Zitat von Momo90

Bitte steinigt mich nicht für eventuelle Blödheiten in den sketches. Ich bin damit ziemlich unerfahren

Definitiv nicht. Jeder fängt mal mit was an und auch der längste Weg beginnt mit dem ersten Schritt

davincino

Bin zufällig über diesen Thread gestolpert. Wenn ihr Infrarot Projekte realisieren wollt kann ich den YS-IRTM empfehlen, gibt's bei AliExpress für 1,30€ das Stück. Ist ein IR Sender und Empfänger mit integriertem De-/Encoder.
Hier gibt's noch ein Beispiel: YS-IRTM Beispiel

Verwende das verlinkte Projekt (bzw das darin verlinkte github Projekt von prahjister) aber ohne 433Mhz Hardware. Über mqtt und node-red leite ich die drei bytes als Parameter an ein Skript. Im Shell Skript wird über case-select die jeweilige Befehlszeile ausgeführt.

Somit steuere ich mit meiner Universalfernbedienung über IR meine Funksteckdosen (triggert domoticz mit rflink), reboot von PC und boot bzw. shutdown NAS.
Theoretisch können weitere wemos mit ys-irtm im Haus verteilt werden, die dann die IR-Signale weiter verteilen.
Finde das mit dem Modul einfacher als mit einzelnen IR Dioden + Empfänger.

don

Gerade ist mein erster ESP32 angekommen.
Freue mich schon aufs Testen.

Wemos D1, NodeMCU, ESP8266

Jetzt mitmachen!

Benutzer online in diesem Thema