Neues Projekt: Onlinestatus für Crowdfunding Ladepunkte

[sirprize]

Meine ersten beiden TODOs habe ich abgearbeitet. Die S0-Pins haben auch Namen bekommen und jeder Pin wird als Struct-Eintrag in folgender Form definiert:

Code: Alles auswählen

  {
    "SpaceOccupied", // pin name
    D5,              // pin number
    HIGH,            // "on" value
    LOW,             // "off" value
    INPUT            // pin mode
  },

On- und Off-Value lassen sich vertauschen, wenn man einen Low-Active-Eingang mit Pullup-Widerstand möchte. Je nach Hardware kann man auch mit INPUT_PULLUP einen internen Pullup-Widerstand aktivieren.

Die Ausgabe des aktuellen Programms lautet wie folgt:

Code: Alles auswählen

CfOnlinestatus starting with 2 S0 pins and 2 digital input pins:
Configured pin number 5 as S0 pin named CounterA
Configured pin number 4 as S0 pin named CounterB
Configured pin number 14 as digital input pin named SpaceOccupied
Configured pin number 2 as digital input pin named ContactorOn
CfOnlinestatus initialisation complete.
s0_CounterA:18:1:4:
s0_CounterB:0:0:5:
di_SpaceOccupied:on:
di_ContactorOn:off:

[Tho]

Cool, das sieht schon mal gut aus.

[sirprize]

Und nun der letzte Commit für heute. Ich habe noch das Abfragen eines Analogpins mit eingebaut. Damit sind meine TODOs fertig.

Wenn ich SAE J1772 richtig verstanden habe, wird die Spannung an PP für die Erkennung eines Steckers verwendet, und zwar so, dass entweder 1,5V (Auto dran), 3V (Stecker wird gerade gezogen) oder 4,5V anliegen. Nimmt man also einen Spannungsteiler mit 10kOhm zu 39kOhm, bekommt man Spannungen von ca. 0,3V / 0,6V / 0,9V. Das lasse ich im Programm als low, mid bzw. high anzeigen. Der Anschluss sollte wie folgt sein: Masse <-> 10k <-> AnalogPin <-> 39k <-> PP

Im Moment habe ich versucht, den Code so allgemein wie möglich zu gestalten. Er müsste (mit Anpassung der Pin-Nummern) auf einem Arduino, ESP8266, MSP430, ... laufen. Einfach die Inputs anschließen, die Daten seriell auslesen und weiterverarbeiten.

Die Festlegung auf ESP8266 hätte den Vorteil, die Daten direkt per Wifi weitergeben zu können. Alternativ kann man auch das beschriebene SIM900-Modul verwenden und GPRS nutzen. In beiden Fällen lässt sich auch MQTT, REST oder was auch immer nutzen.
Ich lasse meinen Code mal so stehen, passe ihn auf Wunsch aber gerne an konkrete Hardware sowie Kommunikationsprotokolle an.

[EVduck]

Sind das nicht 12V 9V und 6V?


Gesendet von iPhone mit Tapatalk

[sirprize]

Ich glaube, 12/9/6 hast du bei CP (Pilot), nicht PP (Proximity). Zumindest verstehe ich die Seiten 11 bis 17 in diesem PDF so.

[DiLeGreen]

Ich fände es gut für den Parkplatzsensor, neben dem Digital-Eingang, direkt z.B. einen HC-SR04 Ultraschall-Sensor abfragen zu können.
http://www.mikrocontroller-elektronik.d ... r-hc-sr04/

[Tho]

Allgemein halten ist gut, dann könnte man am Ende 1,2 oder 3 angepasste Versionen für bestimmte Hardware anbieten. (Ich fände relevant: WLAN, LAN, GSM, LoRaWAN)

[tango]

Hast DU für RoWaLan schon Equipment? Von dem Standard habe ich zwar schon gehört (auch erst vor ein paar Tagen), aber ich hab dafür noch nix in den Fingern gehabt. Von der Bandbreite her müsste es ja für unsere Zwecke ausreichen!

[Tho]

Ja, mein LoRaWAN Gateway läuft schon. Angebunden an das offene Community Projekt https://www.thethingsnetwork.org
Einen Node (The Things Uno = Arduino Leonardo mit LoRa Chip) habe ich auch schon dran. Im Optimalfall schafft ein Node wohl bis 50kb/s. Es ist aber wirklich nicht für größe Datenmengen gedacht, sondern eher zum Übertragen z.B. kleiner Messwertdatensätze. Reicht für uns alle mal.
Die Daten bekommt man als MQQT und kann man dann weiterverarbeiten, z.B. mit dem "Muecke Server" der Ulmer Community.
Reichweitenexperimente habe ich noch keine gemacht, die Community Berichte sind aber recht beeindruckend.

Wir sollten uns aber nicht allzu sehr auf LoRa konzentrieren, dort wo es verfügbar ist könnte man es halt nutzen und ich hätte die Möglichkeit gerne vorgesehen. LAN und WLAN wird aber wesentlich wichtiger sein.

Die Festlegung auf ESP8266 hätte den Vorteil, die Daten direkt per Wifi weitergeben zu können. Alternativ kann man auch das beschriebene SIM900-Modul verwenden und GPRS nutzen. In beiden Fällen lässt sich auch MQTT, REST oder was auch immer nutzen.

Ich denke wir sollten uns für die wichtigsten Anbindungsvarianten jeweils für eine Plattform entscheiden.
Beim ESP8266 bin ich mir nicht ganz so sicher, der ist zwar billig aber meiner Erfahrung nach auch eher instabil wenn der Strom vom USB Netzteil nicht absolut sauber ist.

[sirprize]

Ich habe ein paar neue Commits geschrieben. Erstens die Abfrage des HC-SR04, zweitens das Einfügen unzähliger #defines, mit denen sich Teile des Codes ausblenden lassen. So können wir unterschiedliche Hardware- und Softwarefeatures in einer Datei haben, ohne die gemeinsame Codebasis zu verlieren.

Ein Nachteil: der Code wird etwas unübersichtlich. Dafür können wir den Konfigurationsteil am Anfang der Datei einfacher machen.

Code: Alles auswählen

#define INPUT_S0         1
#define INPUT_DIGITAL    1
#define INPUT_ANALOG     1
#define INPUT_ULTRASOUND 1
#define OUTPUT_SERIAL    1
//#define OUTPUT_WIFI      1
//#define OUTPUT_LAN       1
//#define OUTPUT_LORA      1
#define OUTPUT_GSM       1

Die Ausgabemethoden außer seriell sind noch nicht implementiert. Ich würde dazu mal einen einzelnen Kommunikationsweg (z.B. Wifi) und eine einzelne Methode (z.B. MQTT) implementieren. Was meint ihr?