Hier mal ein paar Fragen und Antworten zum Prototyp einer älteren Version eines RS485 Gateways (PN ist blöd):
ZitatWas ich noch nicht ganz gecheckt habe ist die Spannungsversorgung.
Wenn ich jetzt einen Nano drauf habe, versorge den extern über usb und gebe auf die RS485 klemmen links und rechts 5V dann funktioniert schonmal die Kommunikation. Allerdings ist auf der Leiste an der die digital und analog Pins verzogen sind nirgens Spannung. Muss ich da die strippen manuell ziehen oder geht das auch eleganter? Evtl. Über die Jumper Leisten ?!?
Bei der ersten Version musste man noch eine Verbindung ziehen siehe Fotos.
ZitatWie sieht es aus mit Spannungsregler? Müssen da sonst noch zusatzbauteile drauf? Was hat das mit den Pads zwischen P$2 und P$1 auf sich? Ich möchte das ganze in Zukunft schon über eine externe Einspeisung machen. Wenn ich das richtig sehe sollte das über Klemme 2 + 3 funktionieren oder? Für was ist Klemme 1?
Ich habe hier nen Schaltplan exportiert: https://github.com/ranseyer/MySensors-HW/blob/master/zz:Obselet/MySens-GW-RS485-Nano/V01-Schematic.png
Melde mich später nochmals...
Zum Spannungsregler: Hast du zufällig einen Mini360 ?
https://www.google.de/search?q=mini360&safe=off&source=lnms&tbm=isch
Dann könntest Du optional noch davor und dahinter einen Kondensator verbauen. (Erst mal ohne starten)
ZU den Pads; evtl hilft ja schon das Foto.
Die Brücke habe ich mit Draht gezogen, die MySConnect leiste hat jetzt Saft 😊
Jepp habe den Mini 360 auf einem Board verlötet.
Versorgt der den Nano direkt? Für was ist oben die Sicherung? Was fehlt da sonst noch?
Ich muss auch den rs485 Chip separat vom Nano versorgen über die klemmen 1+4.
Sonst funkt der nicht. Ich hatt das so verstanden das man über 1+4 zusätzliche nodes
Mit Spannung versorgen kann.
Wenn ich keinen 360ernehme und direkt mit 5v auf das Board gehe, welche Möglichkeiten habe ich da?
Grüße
Matze
Ah, verstehe Deine Fragen langsam besser. Also leider wirst du den Schaltplan studieren müssen... :'(
Hier ein Auszug. Die Idee für den ersten Entwurd ist möglichst flexibel zu bleiben.
Einspeisung n(Umfeld von U$3): Erfolgt über den dreipolige Anschluss im 3,5mm Raster oder der Hohlbochse wie bei mir. Wie man sieht wird ohne Sicherung oder Überbrückung dieser wenig passieren.
Verschaltung: Es muss UREG (Unreguliert) z.B. auf den gewünschten Spannungsregler gelegt werden. Der gewünschte Ausgang des Spannungsreglers muss dann ggf. auf VCC an JP19 gelegt werden.
Bedeutet: Hochflexibel in der ersten Verson aber auch ein paar mehr Verbindungen nötig. (Beides entfällt beim Nachfolger, der ist also schlechter und besser. Jedenfalls einfacher.)
(Mein Kreis sollte gedenklich also auch um JP19 gehen...)
Ausgang:
UREG ist direkt an X7-1 verbunden. Wenn du als 12V einspeist kommen da auch 12V raus (Vorsicht! Wenn nicht gewünscht könnte man das an der Sicherung tricksen)
GND ist generell überall direkt verbunden
A+B sind der RS485 Bus
Ah ok, verkabeln ist kein Problem. Wollte nur nichts von vornherein falsch brutzeln.
Die Sicherung ist praktisch nur wenn zuviel Last über die fernspeisung geht das die fällt und der eigentlichen Schaltung nichts passiert. Richtig?
Ich denke ich verstehe den Ansatz langsam.
ich schau mir das nochmal genau an 😄
Grüße
Matze
Ja. Wobei mir die Schaltung auch nicht so wichtig wäre. Aber jedenfalls wird das Netzteil geschützt und sollte nicht abfackeln.
Grund kann also vom Bus extern sein, oder auch die Schaltung selbst. Ich habe zwar noch keinen Arduino gesehen der bei normaler Nutzung einen Kurzschluss verursacht hat, aber man weiss ja nie.
Ich glaub ich habe gerade einen Max487 gehimmelt. zumindest gab er Rauchzeichen von sich.
Ich habe den 360er als Spannungswandler drauf und JP 19 R2in mit UREG gebrückt und R2out mit RAW.
Der Nano hatte daraufhin auch Spannung über die Externen Klemmen.
Wo hängt denn da der Max487zwischen drin? versteh ich nicht ganz. Laut Schaltplan bezieht der seine Spannung von VCC vom Nano.
Eingangsspannung ist 12V Ausgangsspannung hab ich auf 5,0 V eingestellt am 360
grüße
Matze
Ps.: wenn du noch hast bräuchte ich praktisch einen 487 :)
RXOut / R2Out ist der Ausgang des Spannungsreglers
RAW sind in deinem Fall wohl 12V
=> Diese hättest Du wie ich das verstehe verbunden, also 5V direkt mit 12V.
Wenn du also 12V auf VCC geschaltet hast, dann ist der Max* defekt und der Arduino zumindest sehr warm geworden.
Sinnvoll wäre den Spannungsregler-Ausgang / Out auf VCC zu legen. dann hat der Arduino+Max* 5V und der "Bus" 12V.
PS: Max 487 hab ich genügend...
Alles klar, teste ich wenn die Bauteile da sind. Dachte RAW sind auch 5V.
Naja mit Verlusten ist zu rechnen ;)
Grüße
Matze
Mal ne blöde Frage: Wie bist du mit den Mini360 StepDown Modulen zufrieden ?
Bin mir da unschlüssig, und mechanisch sind diese auf jeden Fall blöd um diese irgendwo zu integríeren...
Ansich schön kompakt. Hab die auf stiftleiste verlötet. Montage damit ok.
Aber an dem Poti eine vernünftige Spannung einzustellen ist sehr schwierig. Gefühlt ne halbe Stunde rumgeeiert bis da mal annähernd 5V rausgekommen sind.
Grüße
Matze
Stromzähler und Wasseruhren Node laufen jetzt auf rs485. Das ganze noch in Dosen verpacken und man sieht nichts mehr davon! Wenn die neuen Bauteile da sind wird noch der gaszähler und die Zisterne angepackt.
Gibt es eigentlich eine Möglichkeit direkt am Pi die serielle Konsole zu checken was über das Gateway rein kommt?
Grüße
Matze
gibt es Erfahrungswerte bei mehreren Nodes an einem RS 485 Bus?
Habe jetzt den Gaszähler angebunden aber es kommen keine Werte an. Readings werden nicht Übertragen/erstellt etc.
Der Sensor wird zwar in FHEM erkannt, als Gas Meter, Versionsstände kommen und das wars.
Nach langem hin und her kamen dann auch readings. allerdings lässt es den value11 wert nicht setzen.
Sieht irgendwie nach einem Kommunikationsproblem aus. braucht man ab einer bestimmten Teilnehmerzahl Abschlusswiderstände?
grüße
Matze
Hallo zusammen,
was mehrere Nodes und die Widerstandsfrage angeht, kann das etwas tricky sein, wenn man die allgemien verbreiteten LC-Tech Module hat, da sind nämlich zu viele drauf ;) .
Eine gute Zusammenfassung zum "optimalen" elektrischen Design ist z.B. hier zu finden: https://dan.bemowski.info/2017/09/16/rs485-communication-techniques/, dann gibt es hier noch ein interessantes Tool: http://alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp
Kurz gefaßt würde ich empfehlen, nicht gleich alle Widerstände von den Modulen zu löten, sondern mit den 120Ohm's in den "mittleren" Nodes anzufangen (lt. Spec braucht man die nur am Beginn und Ende vom Bus).
Manche Dinge muß man evtl. auch durch den Code abfangen, da bin ich aber auch noch nicht ganz durch. Von daher wäre hilfreich zu wissen, ob es immer dieselben Nodes sind, die Schwierigkeiten machen (und wenn ja: den Code dazu zu kennen). Was uU. auch helfen könnte, wäre die serielle HW-Schnittstelle zu benutzen, ich habe den Verdacht, dass altsoftserial irgendeinen Puffer hat, mit dem man die Nodes bei Überfüllung komplett abschießen kann (Verdacht=diffuses Gefühl in diese Richtung).
Und: Wenn nichts geht, miß mal die Spannung zwischen den beiden Leitungen (sollte (?) <2 V sein) und GND und den drei Daten-Leitungen Arduino <-> Modul.
Bin mal gespannt auf eure Ergebnisse, ich bin da auch noch etwas am Experimentieren...
Gruß, Beta-User
Ich habe die MAX487 Module verbaut. Hier sind weder Widerstände vorne noch hinten. Ist mit 1x Gateway und 2x Nodes auch auf anhieb stabil gelaufen.
Jetzt habe ich in einem anderen Board gelesen das es mit 120 Ohm wohl schwierig wird weil das den Bus auf Low zieht.
Dieser aber wohl auf High gehalten werden muss. Abhilfe soll sowohl vorne als auch hinten am Busende folgendes schaffen:
VCC<-> 390Ohm <-> A <->120 Ohm <-> B <-> 390 Ohm <-> GND
Ich besorge mir jetzt mal ein paar Widerstände und teste weiter aus. Die Spannung messe ich bei der gelegenheit auch mal nach - kann ja nicht schaden :)
Grüße
Matze
Interessant, dass es so dann auch funktioniert.
In dem unteren der Links kann man ausrechnen, welche Pullup-/Pulldown-Werte bei welchen Kabeln und Längen gut sind. Soweit ich das verstanden habe (Achtung: Laie...), sollten die am Besten in der Mitte des Bus sitzen.
Aber 390 Ohm auf jeder Seite kommt mir niedrig vor. Auf den Modulen sind jeweils 10k verbaut, wenn du also was hast mit um die 1k, würde ich damit mal anfangen (die 2*120 Ohm bleiben so).
Gruß, Beta-User
Hmm da kommen bei 30 Meter Buslänge ca 540 Ohm raus. Auf dem Rechner wird nur am Anfang der Pullup / Pulldown gesetzt.
Interessant. Ich geh mal Widerstände schnacken :)
grüße
MAtze
Mir scheint diese Variante ganz nett:
Stand dürfte aber auf jeden Fall zu seinen einen (jeden) Bus am Anfang und am Ende zu terminieren. Also niemals in der Mitte, oder noch öfters.
Quelle:
https://raw.githubusercontent.com/ranseyer/MySensors-HW/master/MySensors-HM-easy-PCB-RFM-CC1101-RS485-NRF/1_Standard/Schematic010.png
(Den Text unter dem MAX48* beachten...)
ICh habe das Beispiel 120 Ohm auf A<->B und 390 Ohm A<->VCC und B<->GND
umgesetzt. Ergebnis ist unverändert. Die Beiden Nodes die schn funktionierten gehen immer noch.
Das letzte Node sendet zwar beim boot das es da ist, aber keine Readings mehr.
Bei einer Node Eingangsversorgung über USB von 4.6 V, liegt der Bus auf 0,33V
Entweder passen die Widerstände nicht, oder es ist ein error drin!
grüße
Matze
*******************************
*
* REVISION HISTORY
* Version 1.0 - Henrik Ekblad
* Version 1.1 - GizMoCuz
*
* DESCRIPTION
* Use this sensor to measure volume and flow of your house Watermeter.
* You need to set the correct pulsefactor of your meter (pulses per m3).
* The sensor starts by fetching current volume reading from gateway (VAR 1).
* Reports both volume and flow back to gateway.
*
* Unfortunately millis() won't increment when the Arduino is in
* sleepmode. So we cannot make this sensor sleep if we also want
* to calculate/report flow.
* http://www.mysensors.org/build/pulse_water
*/
// Enable debug prints to serial monitor
#define MY_DEBUG
// Enable RS485 transport layer
#define MY_RS485
// Define this to enables DE-pin management on defined pin
#define MY_RS485_DE_PIN 2
// Set RS485 baud rate to use
#define MY_RS485_BAUD_RATE 9600
#define MY_NODE_ID 104
#include <MySensors.h>
#define DIGITAL_INPUT_SENSOR 3 // The digital input you attached your sensor. (Only 2 and 3 generates interrupt!)
#define PULSE_FACTOR 100 // Nummber of blinks per m3 of your meter (One rotation/liter)
#define SLEEP_MODE false // flowvalue can only be reported when sleep mode is false.
#define MAX_FLOW 30 // Max flow (l/min) value to report. This filters outliers.
#define CHILD_ID 1 // Id of the sensor child
unsigned long SEND_FREQUENCY =
30000; // Minimum time between send (in milliseconds). We don't want to spam the gateway.
MyMessage flowMsg(CHILD_ID,V_FLOW);
MyMessage volumeMsg(CHILD_ID,V_VOLUME);
MyMessage lastCounterMsg(CHILD_ID,V_VAR1);
double ppl = ((double)PULSE_FACTOR)/1000; // Pulses per liter
volatile unsigned long pulseCount = 0;
volatile unsigned long lastBlink = 0;
volatile double flow = 0;
bool pcReceived = false;
unsigned long oldPulseCount = 0;
unsigned long newBlink = 0;
double oldflow = 0;
double volume =0;
double oldvolume =0;
unsigned long lastSend =0;
unsigned long lastPulse =0;
void setup()
{
// initialize our digital pins internal pullup resistor so one pulse switches from high to low (less distortion)
pinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
pulseCount = oldPulseCount = 0;
// Fetch last known pulse count value from gw
request(CHILD_ID, V_VAR1);
lastSend = lastPulse = millis();
attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, FALLING);
}
void presentation()
{
// Send the sketch version information to the gateway and Controller
sendSketchInfo("Gas Meter", "1.0");
// Register this device as Gasflow sensor
present(CHILD_ID, S_GAS);
}
void loop()
{
unsigned long currentTime = millis();
// Only send values at a maximum frequency or woken up from sleep
if (SLEEP_MODE || (currentTime - lastSend > SEND_FREQUENCY)) {
lastSend=currentTime;
if (!pcReceived) {
//Last Pulsecount not yet received from controller, request it again
request(CHILD_ID, V_VAR1);
return;
}
if (!SLEEP_MODE && flow != oldflow) {
oldflow = flow;
Serial.print("l/min:");
Serial.println(flow);
// Check that we dont get unresonable large flow value.
// could hapen when long wraps or false interrupt triggered
if (flow<((unsigned long)MAX_FLOW)) {
send(flowMsg.set(flow, 2)); // Send flow value to gw
}
}
// No Pulse count received in 2min
if(currentTime - lastPulse > 120000) {
flow = 0;
}
// Pulse count has changed
if ((pulseCount != oldPulseCount)||(!SLEEP_MODE)) {
oldPulseCount = pulseCount;
Serial.print("pulsecount:");
Serial.println(pulseCount);
send(lastCounterMsg.set(pulseCount)); // Send pulsecount value to gw in VAR1
double volume = ((double)pulseCount/((double)PULSE_FACTOR));
if ((volume != oldvolume)||(!SLEEP_MODE)) {
oldvolume = volume;
Serial.print("volume:");
Serial.println(volume, 3);
send(volumeMsg.set(volume, 3)); // Send volume value to gw
}
}
}
if (SLEEP_MODE) {
sleep(SEND_FREQUENCY);
}
}
void receive(const MyMessage &message)
{
if (message.type==V_VAR1) {
unsigned long gwPulseCount=message.getULong();
pulseCount += gwPulseCount;
flow=oldflow=0;
Serial.print("Received last pulse count from gw:");
Serial.println(pulseCount);
pcReceived = true;
}
}
void onPulse()
{
if (!SLEEP_MODE) {
unsigned long newBlink = micros();
unsigned long interval = newBlink-lastBlink;
if (interval!=0) {
lastPulse = millis();
if (interval<500000L) {
// Sometimes we get interrupt on RISING, 500000 = 0.5sek debounce ( max 120 l/min)
return;
}
flow = (60000000.0 /interval) / ppl;
}
lastBlink = newBlink;
}
pulseCount++;
}
Der Sketch ist ein leicht geänderter Water Meter pulse mit einem tcrt5000 auf D3 der beim Gaszähler auf der 6 einen reflektierenden
Punkt erfasst. Die Lichtschranke löst auch brav aus (erkennbar an der LED).
Die Readings flow1, value11 und volume1 werden nicht erzeugt.
Grüße
Matze
Funktioniert dieser Node denn generell ? (Also z.B. alleine am Bus ?)
(4,6V ist m.E. auch nicht sooo doll. Habe festgestelt mit 3,3V geht es zuverlässig gar nicht... Oder hat da noch gemand genauere Erfahrungen zur Spannung?)
Ich habe den Sketch auf 2 verschiedenen Nanos drauf. jeweils mit unterschiedlicher ID.
Auf dem Steckbrett am Bus dran hats funktioniert und die Pings der Lichtschranke wurden hochgezählt.
Am Zähler mit den anderen Nodes komischerweise nicht mehr. Busleitungslänge ist an der stelle ca. 30m
Bei beiden Nanos das gleiche Szenario.
Ich habe die Widerstände am Gateway und am letzten Node montiert. Die geringe Busspannung stört mich dabei ein wenig.
Hatte mal jemand was von 2,7V geschrieben was drauf sein sollte. Da ist 0.33V natürlich ein Stück weit von weg.
Am Gateway hol ich mir die 5V vom Pi. da könnte ich nochmal messen was da effektiv durch geht.
Pi gibt dem Node 4,2V ich habe jetzt nochmal ne brücke drauf gelötet das die Spannung vom Pi direkt auf den Pullup geht.
bringt auf dem Bus am Pi gemessen 0,5V Spannung. Es wird leicht besser funktioniert aber immer noch nicht :(
Doofe Frage: Paßt das IO?
(Wenn du mehrere hast, kann es sein, dass die node dem falschen Interface zugeordnet wird, ist mir jedenfallst auch schon passiert. Es sind dann auch Fehler im log zu sehen: die verworfenen, weil nicht zuordenbaren readings ;) ).
Wenn es das nicht ist, und am Anfang und Ende des Bus je 120 Ohm verbaut sind, muß ich nach dem code-Fix suchen...
Denn an sich scheint das elektrische Design ja ok zu sein.
Was die Spannung angeht: zwischen A und B sollte nur dann Spannung anliegen, wenn gesendet wird, sonst eigentlich 0V (jedenfalls, wenn ich die diversen Quellen dazu richtig verstehe).
Zitat+-200mV is the magic number with rs485. rs485 line 3 states:
- Va - Vb < -0.2V = "1"
- Va - Vb > 0.2V = "0"
- |Va - Vb| < 0.2V = "idle"
As I know the line should be in idle state when nobody is sending.
IO in fhem meinst du? Jepp passt ist MySensorsGateway
Das meinte ich.
Ich habe 2 MySensors-GW's (für nRF und RS485, beide seriell). Manchmal scheint die Zuordnung von neuen Nodes nicht auf das richtige IO gemappt zu werden (warum auch immer, kann auch sein, dass es an einer "alten" NodeID liegt, an die sich configDB noch erinnert. Dann kommen tatsächlich nur die "Kopfdaten" an bzw. werden aktualisiert.
Scheint ja aber nicht das Problem zu sein.
Daher also der Code:
In den RS485-Teil der Sketche das einfügen
#define MY_RS485_SOH_COUNT 3MyTransportRS485.cpp wie folgt ändern:
Am Anfang einfügen:
#if !defined(MY_RS485_SOH_COUNT) #define MY_RS485_SOH_COUNT 1 #endif
Im "sending code" das
// Start of header by writing multiple SOH for(byte w=0; w<1; w++) { _dev.write(SOH); } wie folgt ändern:
// Start of header by writing multiple SOH for(byte w=0; w<MY_RS485_SOH_COUNT; w++) { _dev.write(SOH); }
Das hatte ich erst vermutet und deshalb schon mit frischen Node IDs getestet.
Muss ich auch die funktionierenden nodes umflashen?
Erst mal nicht, denke ich.
Bzw: auf den Modulen sind 20k pull-Widerstände drauf. Würde also ggf. da auch mit höheren Werten mal testen.
Wo sind da pullups? Ich hab die MAX 487 drauf, nicht die rs485 Arduino Module
Wollte nur sagen, dass ich 390 Ohm vom Gefühl her immer noch für sehr niedrig halte... (Steno, da Mobil)
das Node ist umgelfasht. Allerdings ohne Erfolg :(
Beim Start wird wieder das Node angelegt aber es kommen keine Readings dazu
1. Bist du sicher, dass etwas gesendet wird (müßte über MY_DEBUG und die serielle Konsole zu erkennen sein).
Der Sketch sieht eigentlich ok aus.
2. Wenn etwas gesendet wird, steht dazu etwas im Log oder ist im Event-Monitor zu erkennen?
3. Versuche mal, den als S_WATER zu präsentieren, ob das was ändert.
Wenn alles bis dahin nichts hilft:
4. Die readings werden uU. aktualisiert, aber solange sie nicht auf der FHEMWEB-Seite angezeigt werden, sieht man erst mal nichts, erst nach einem Browser-Refresh. Und es dauert natürlich auch, bis die erste Übertragung kommt, vorher macht es keinen Sinn zu refreshen.
5. Mach' soch mal ein list vom IO und von der Node.
So ich hab die Node jetzt nochmal an den PC angeschlossen das ich seh was seriell raus geht.
0 MCO:BGN:INIT NODE,CP=RSNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=0
5 TSM:INIT:TSP OK
7 TSM:INIT:STATID=105
9 TSF:SID:OK,ID=105
11 TSM:FPAR
28 TSF:MSG:SEND,105-105-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
488 TSF:MSG:READ,0-0-105,s=255,c=3,t=8,pt=1,l=1,sg=0:0
493 TSF:MSG:FPAR OK,ID=0,D=1
2035 TSM:FPAR:OK
2036 TSM:ID
2037 TSM:ID:OK
2039 TSM:UPL
2058 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2084 TSF:MSG:READ,0-0-105,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2091 TSF:MSG:PONG RECV,HP=1
2093 TSM:UPL:OK
2095 TSM:READY:ID=105,PAR=0,DIS=1
2116 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2141 TSF:MSG:READ,0-0-105,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2168 TSF:MSG:SEND,105-105-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2193 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2230 TSF:MSG:READ,0-0-105,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2262 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=11,pt=0,l=9,sg=0,ft=0,st=OK:Gas Meter
2288 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
2312 TSF:MSG:SEND,105-105-0-0,s=1,c=0,t=37,pt=0,l=0,sg=0,ft=0,st=OK:
2318 MCO:REG:REQ
2337 TSF:MSG:SEND,105-105-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2361 TSF:MSG:READ,0-0-105,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2366 MCO:PIM:NODE REG=1
2368 MCO:BGN:STP
2386 TSF:MSG:SEND,105-105-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:
2393 MCO:BGN:INIT OK,TSP=1
Auch ohne Endwiderstände und gedöns wird registriert. Gesendet aber nichts.
Als nächstes ist jetzt der Watermeter sketch drauf den ich schon im Einsatz habe. gleiches ergebnis.
Habe mir den Sketch nochmal angesehen, vermutlich ändert sich der pulsecount nicht.
In meinem puls-count-interrupt-Sketch sieht das in before() so aus:
pinMode(DIGITAL_INPUT_SENSOR, INPUT_PULLUP);
digitalWrite(DIGITAL_INPUT_SENSOR, HIGH);
pulseCount = oldPulseCount = 0;
attachInterrupt(SENSOR_INTERRUPT, onPulse, FALLING);
Zwischenzeitlich habe ich noch ein neues PCB aufgebaut um das auszuschließen. - selbes ergebnis
Die Sketch Änderung brachte leider auch keine Besserung.
Konsole des Nodes:
0 MCO:BGN:INIT NODE,CP=RSNNA--,VER=2.1.1
3 TSM:INIT
4 TSF:WUR:MS=0
5 TSM:INIT:TSP OK
7 TSM:INIT:STATID=102
9 TSF:SID:OK,ID=102
11 TSM:FPAR
28 TSF:MSG:SEND,102-102-255-255,s=255,c=3,t=7,pt=0,l=0,sg=0,ft=0,st=OK:
108 TSF:MSG:READ,0-0-102,s=255,c=3,t=8,pt=1,l=1,sg=0:0
113 TSF:MSG:FPAR OK,ID=0,D=1
2035 TSM:FPAR:OK
2036 TSM:ID
2037 TSM:ID:OK
2039 TSM:UPL
2058 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=24,pt=1,l=1,sg=0,ft=0,st=OK:1
2084 TSF:MSG:READ,0-0-102,s=255,c=3,t=25,pt=1,l=1,sg=0:1
2091 TSF:MSG:PONG RECV,HP=1
2093 TSM:UPL:OK
2095 TSM:READY:ID=102,PAR=0,DIS=1
2116 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=15,pt=6,l=2,sg=0,ft=0,st=OK:0100
2141 TSF:MSG:READ,0-0-102,s=255,c=3,t=15,pt=6,l=2,sg=0:0100
2168 TSF:MSG:SEND,102-102-0-0,s=255,c=0,t=17,pt=0,l=5,sg=0,ft=0,st=OK:2.1.1
2193 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=6,pt=1,l=1,sg=0,ft=0,st=OK:0
2230 TSF:MSG:READ,0-0-102,s=255,c=3,t=6,pt=0,l=1,sg=0:M
2260 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=11,pt=0,l=9,sg=0,ft=0,st=OK:Gas Meter
2288 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=12,pt=0,l=3,sg=0,ft=0,st=OK:1.0
2312 TSF:MSG:SEND,102-102-0-0,s=1,c=0,t=37,pt=0,l=0,sg=0,ft=0,st=OK:
2318 MCO:REG:REQ
2337 TSF:MSG:SEND,102-102-0-0,s=255,c=3,t=26,pt=1,l=1,sg=0,ft=0,st=OK:2
2361 TSF:MSG:READ,0-0-102,s=255,c=3,t=27,pt=1,l=1,sg=0:1
2366 MCO:PIM:NODE REG=1
2368 MCO:BGN:STP
2386 TSF:MSG:SEND,102-102-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:
2393 MCO:BGN:INIT OK,TSP=1
32410 TSF:MSG:SEND,102-102-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:
62411 TSF:MSG:SEND,102-102-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:
92412 TSF:MSG:SEND,102-102-0-0,s=1,c=2,t=24,pt=0,l=0,sg=0,ft=0,st=OK:
Was auffallend ist im Log, die beiden anderen Nodes die funktionieren werden auch nicht angezeigt.
Viele Grüße
Matze
Moin zusammen, zwei Anmerkungen noch:
- Zu meinem Code gehört im Kopfteil noch ein
#define SENSOR_INTERRUPT DIGITAL_INPUT_SENSOR-2 // Usually the interrupt = pin -2 (on uno/nano anyway)
- Dann würde ich zum Testen in den onPulse() einen serial.print reinmachen um zu testen, wenn ein Puls erkannt wird. Da scheint ja das ganze Problem zu liegen, dass erst gar keine Pulse gezählt werden.
da habe ich das drin stehen
#define MY_RS485_DE_PIN 2
normal müsste ich über den Bus im seriellen Monitor doch auch die anderen Nodes sehen können oder?
weil node 100 und 101 funken munter vor sich hin und füttern schön fhem mit readings.
das node 102 mit dem ich jetzt das problem habe zeigt mir aber nur selbiges im Monitor an.
Für mein Verständnis müssten doch auch 100 und 101 angezeigt werden sobald daten durchgehen?!?
Zum Verständnis: Ich habe 1x serielles Gateway am Raspi das fhem füttert (braucht das auch eine ID=?!?)
1x Node ID 100 Stromzähler
1x Node ID 101 Wasserzähler
...das sind zwei unterschiedliche Dinge:
In deinem Sketch verwendest du (#20)
attachInterrupt(digitalPinToInterrupt(DIGITAL_INPUT_SENSOR), onPulse, FALLING);
Das scheint aus irgend einem Grund nicht zu funktionieren. Mein Vorschlag war jetzt, digitalPinToInterrupt() nicht zu verwenden und stattdessen "den Fußweg" zu nehmen (Interrupt-Nr. manuell festlegen (das war das, was gestern noch gefehlt hatte) und die Interrupt-Nr. direkt zu verwenden).
Die muß für PIN3 hat 1 sein (PIN2 hat interr. 0). Daher kommt das "-1".
Hast du mal einen serial print in die isr eingebaut um zu prüfen, ob der überhaupt einen fallenen Pegel detektiert?
Ich bau den Sketch nochmal um :)
Im Print hab ich nichts, habe aber auch schon probiert mit ner brücke eine Zwangsauslösung auf dem Nano zu machen
Ohne Erfolg!
Das komische ist, ich habe genau den selben Watermeter Sketch erfolgreich auf dem node 101 laufen.
Arduino kaputt?
Kannst du einen anderen nehmen?
Hört sich für mich auch wie ein HW Problem an.
Mal etwas Background auf Seite 13: https://datasheets.maximintegrated.com/en/ds/MAX1487-MAX491.pdf
Arduinos muss ich mir wenn erst welche bestellen.
Der Restbestand ist lauffähig verbaut! ;D
so neue Arduino sind da - selbes problem >:(
Ich habe jetzt auch mal den funktionierenden Wasserzähler arduino an die stelle gesetzt an der ich die ganze Zeit teste. Funktioniert auf anhieb! Den neuen Arduino mit dem identischen sketch am Wasserzähler funktioniert nicht. Irgendwas passt da nicht.
Ich habe auch die arduino IDE aktualisiert. Nochmal die Mysensors lib neu eingespielt.
Ein bus problem und sketch problem würde ich jetzt fast ausschließen.
Irgendwie erzeugt der arduinos keine interrupts und readings. ansonsten sieht der Netzwerkverkehr gut aus. Ich habe auch 2 verschiedene PCB getestet. Kein Erfolg.
Grüße
Matze
Nächster Versuch: an anderen Rechner Frisch installierte IDE und mysensors lib 2.1.1
Gateway und sensornode geflasht, in der seriellen Konsole melden sich beide, das node sendet
Aber keine pulse.
Getestet mit dem Original Watermeter sketch und Gateway sketch für rs485
Zum testen nochmal mit 2.2.0 Beta. Selbes Ergebnis!
Noch jemand eine Idee? Bin langsam ratlos!
Grüße
Matze
Nach langem hin und her habe ich es denk ich hinbekommen.
Was jetzt der Fehler war kann ich nicht genau sagen. Ich habe dem Node nochmal eine andere Node ID verpasst die noch nicht vergeben war. Kann es sein das irgendwo im System die ID gespeichert wird und deshalb die abfragen anders sind?
Desweiteren denke ich habe ich teilweise den Fehler gemacht den Arduino auf dem PCB zu flashen und da kamen dann Daten über den Bus. Gibt es dazu schon erfahrungswerte?
Und zu guter letzt habe ich jetzt die Bus Klemmen entfernt und festsitzende Steckbrücken eingesetzt nachdem ich sporadische Busausfälle hatte.
Nachdem das jetzt seit 2 Stunden läuft hab ich mich mal kurz an ein icon für den Gaszähler gemacht. Wem sowas noch fehlt, häng ich es an.
Viele Grüße
Matze
Zitat von: Beta-User am 11 November 2017, 19:13:22
Wollte nur sagen, dass ich 390 Ohm vom Gefühl her immer noch für sehr niedrig halte...
Zur Ergänzung, was das Widerstands-Thema angeht:
Habe vorhin mal testweise meine pullup- und pulldown-Widerstände aus der Busmitte entfernt (je 1k). Ergebnis: der Bus läuft (mindestens, das teste ich gerade) genauso stabil...
Wenn jemand als Probleme hat, dass readings verloren gehen bzw. nicht am GW ankommen, wäre es einen Test wert, nur die Widerstände am Busende (2*20k für pullup bzw. -down und 120Ohm) und den 120-er am GW dranzulassen bzw. einzubauen (da sind bei mir auch noch die 2*20k dran, da ich die fertigen Module eingebaut habe).
Gruß, Beta-User
Danke für die Rückmeldung. Das sollte immer so gemacht werden. Niemals den Bus in der Mitte terminieren!
Zitat von: Ranseyer am 19 November 2017, 15:11:27
Danke für die Rückmeldung. Das sollte immer so gemacht werden. Niemals den Bus in der Mitte terminieren!
...da hatte ich vermutlich in meiner Verzweiflung irgendwas falsch interpretiert...
Kaum liest man das Handbuch mit Verstand, werden die Dinge (mal wieder) klarer :o
Seit dem 17. liefen Gateway + 4 nodes stabil. Seit heute morgen bekomme ich vom Stromzähler keine Readings mehr. Strom, Gas und wassernode hängen an der selben Stromversorgung. Von Gas und Wasser kommen auch nach wie Vor readings.
Bustechnisch hängt es mitten drin.
Hat von euch schonmal jemand etwas vergleichbares gehabt? Wie lange sind eure arduinos dauerhaft an und funken. Ich gehe davon aus das es nach einem Neustart wieder funktioniert. Werde ich heute Abend testen. Möchte nur die Umstände verstehen.
Viele Grüße
Matze
Zitat von: smoudo am 27 November 2017, 13:11:57
Hat von euch schonmal jemand etwas vergleichbares gehabt?
Leider ja, allerdings bin ich noch nicht dahintergestiegen, an was es im Detail ggf. hängt. (Bei mir waren es leider viele Themen, die nach und nach als Fehlerquelle auszuschließen waren).
Hast du eine Idee, ob die Node sich komplett aufgehangen hat, oder ob nur die Kommunikation dieses einen Arduinos gestört war/ist? Wenn möglich, miß' bitte vor dem reset die diversen Spannungen rund um den RS485-Baustein bei der Node, die Probeme macht.
Ist da außer dem Impulszähler noch was drauf? Insbesondere etwas, das interne Timer nutzt - z.B. PWM, Servo oder 1wire?
Nutzt Du den SOH-Count-Patch oder HW-serial?
Ich hab auf D3 einen lm393 IR Board dran. Sonst nix. Seriell komm ich da leider schlecht dran ohne reset.
Softwareseitig ist der Standart powermeterpulse Sketch drauf mit dem rs485 com Layer und fester ID
Wie meinst du das mit Bus messen. Spannung an den busklemmen des nodes?
Was ich komisch finde, ist das es nach relativ langer Zeit im Betrieb aussteigt. Versorgung des nanos ist über klemmen, nicht per USB.
Viele Grüße
Matze
Die einzige Änderung am System war gestern Nachmittag am gaszähler. Da habe ich die Lichtschranke gegen einen Reed Kontakt getauscht. Software ist gleich geblieben. Lediglich Neustart der 3 nodes die am selben Netzteil hängen.
Viele Grüße
Matze
Zitat von: smoudo am 27 November 2017, 14:06:55
Was ich komisch finde, ist das es nach relativ langer Zeit im Betrieb aussteigt.
Das hatte ich auch schon mehrfach - zu meinem Leidwesen auch noch (vermutlich) mit unterschiedlichen Ursachen. Ich will dich daher jetzt auch nicht mit Details und dem vollen möglichen Programm zuwerfen, sondern das irgendwie eingrenzen, damit ggf. dauerhaft Ruhe - auch für andere ist ;) .
Fehlerursachen können sein:
- Probleme mit dem Bus an sich oder auch einer anderen Node
Ist m.E. hier eher sehr unwahrscheinlich, höchstens denkbar wäre, dass die erzeugten Spannungspegel bei dieser Node irgendwie so im Grenzbereich liegen, dass das Signal gerade nicht mehr erkannt wird. Ich hatte z.B. auch den Fall einer Node, die kontinuierlich den Spannungspegel beeinflußt hat, so dass erst von da (oder einer anderen Node) nichts mehr kam und dann am Ende der Spannungspegel so hoch war, dass keine Node mehr senden konnte. Nach einem Reset der problematischen Node war alles wieder ok, aber eben nur bis zum nächsten Mal (das scheint durch eine gewisse Inkompabilität zwischen AltSoftSerial und 1-wire gekommen zu sein).
Zu den Messungen: Zum einen zwischen den A-B-Busklemmen jeweils an der Node (sollte eigentlich gegen 0V gehen) sowie bei beiden gegen GND, zum anderen aber auch DI + RO + RE/DE des Bus-Bausteils jeweils gegen GND. Du mußt da also nicht seriell ran...
- Probleme auf der Node bzw. im Zusammenspiel mit dem RS485-Baustein.
Hier kann obige Messung helfen rauszufinden, ob da irgendwas blockiert, und ggf. aus welcher Ecke das kommt...
Den geänderten Header-Code verwendest du ja nicht, und auch die Baud-Rate ist demnach Standard.
Messungen mache ich später, wobei am rs chip auch schwierig weil smd und auf pcb verlötet welches in einer AP Dose sitzt.
Ich habe gerade mal gemessen. Zwischen a um b sind 0,7V
Zwischen a und gnd 2,8V und b und gnd 2,2V
Wie vermutet komm ich an den Rest nicht ran,
Jetzt habe ich den Strom von den nodes und wieder drauf. Anders als erwartet geht jetzt gar nichts mehr.
Danach habe ich das Gateway vom raspy gezogen und wieder rein. Keine Kommunikation.
Das Gateway wechselt auch mehrfach connect / disconnect.
Node 4 was stand alone läuft bringt auch keine Werte mehr. >:(
Irgendwie alles nicht nachvollziehbar.
Viele Grüße
Matze
Das Gateway ist per USB am Raspberry ?
Dann kann das Problem mit dem Gateway doch nur liegen:
-GW
-Raspberry
-Kabel
PS: Die Spannungsversorgung des GW ist bestimmt auch relevant bei RS485. (Und der Raspberry in dieser Hinsicht evtl etwas schwierig? Wenn das so ist ggf. überlegen wie das GW stabile 5V bekommen könnte)
Hast du Vorschläge wie man das realisieren kann ohne Stromkreise zu kreuzen? Ich weiß nicht wie der raspy auf fremdstrom über usb vom Gateway reagiert. Ich könnte die endwiderstände des buses fremd versorgen.
Sorry ich versuche so gut es geht keine Raspberrys zu nutzen, daher habe ich keinen konkreten Tipp.
Aber ich sag mal so: Ich würde mich durchaus trauen die selben 5V. die am Eingang liegen plus GND nochmals extra zu verbinden (falls es wirklich knapp ist). Ich würde mich auch trauen bis zu 10% mehr Eingangsspannung anzulegen.
Was ich aber schon gemerkt habe bei meinen wenigen Raspberry-Experimenten: Gutes Netzteil und und USB-Kabel mit wirklich dicken Adern / niedrigem Widerstand hat tatsächlich Probleme reduziert.
Ich hab ja null konkrete Ahnung von deinem Problem. :o
Vorab: bei meinen ersten Fehlern hatte ich auch das GW stark im Verdacht, zwischenzeitlich denke ich, das ist mit die stabilste Komponente in dem ganzen Setup (aktuell:
| state | opened | 2017-11-11 18:04:23) |
Aber solche Fehlerbilder, wo plötzlich scheinbar gar nichts mehr logisch ist, kenne ich leider auch...
Was ich nicht beschwören will ist, ob mein GW nicht SOH-gepatcht ist (3-fach-Sendung des Daten-Headers).
Jedenfalls nach meiner Erfahrung ist - mindestens seitdem - das GW selten das Problem (hatte mal eines, das seinen Code vergessen hatte, aber sonst: falsche Verdächtigungen?..).
Zur Stromversorgung:
Früher hatte ich die USB-Geräte an einem Hub, der an der gleichen Versorgung hing wie der Pi/die Amlogic-TV-Box, jetzt (ThinClient) ist das eh' kein Thema mehr, der scheint genug Saft zu liefern. Für RS 485 sollte es reichen, nur die Datenleitungen anzuklemmen, und keine Widerstände an der Stelle (außer 120 Ohm zwischen A-B). Empfohlen wird immer, GND zu verbinden, aber da das bei mir unterschiedliche Spannungsversorgungen sind habe ich das auch nicht so (außer den 20k-Widerständen, die bei den fertigen Modulen drauf sind).
Wenn nichts mehr geht: Immer Spannung zwischen A+B messen. Liegen da mehr als 2V an, nacheinander die Arduinos rebooten, einer sorgt für diesen Ärger.
Dann: meine Nodes starten alle ohne GW-Verbindung, vielleicht liegt es beim gleichzeitigen Start an Kollisionen auf dem Bus?
ich habe jetzt mal an meinem testnode die serielle konsole angeschmissen und da sehe ich alle nodes. liegt wohl wirklihc am gateway.
Ich patch da erstmal beta 2.2.0 jetzt drau fund schau weiter.
Anmerkungen noch:
- Das GW-reboot-Problem kann neben Spannungsproblemen am Pi auch von der Board-Def in der Arduino-IDE kommen. Es gab da eine ganze Zeit lang Probleme, die hier im Forum auch schon Thema waren. Was für eine Version nutzt du da (=>Board-Manager)?
- Es ist generell nach meiner Erfahrung besser, die Beta-Version von MySensors zu nehmen, ich dachte, das wäre soweit klar ;) . U.A. deswegen "Beta-User" ;D .
- Mit dem SOH-Patch war das in Post #27 gemeint.
Gruß und hoffentlich viel Erfolg,
Beta-User
Bei dem Namen währe alles andere auch fahrlässig ;)
Bin gerade ein Stück weiter. Hatte niche im breadboard in der Nähe und habe
Über die Steckleiste provisorisch 5v eingespeist. Gateway umpatchen habe ich mir jetzt erstmal gespart.
Und siehe da es läuft auf Anhieb. Warum der Spaß jetzt 2 Wochen funktioniert hat würde mich trotzdem
Interessieren!
Jetzt muss ich mir erstmal ernsthaft eine vernünftige 5V Schiene einfallen lassen!
Viele Grüße
Matze
Ps. Was ein Glück hat ranseyer genug vcc und gnd pins auf den Platten vorgesehen! ;D
Also zu wenig Saft von der Himbere aus ?
Zitat von: Ranseyer am 30 November 2017, 16:32:35
Also zu wenig Saft von der Himbere aus ?
Wenn es das war (und danach sieht es aus): ...so einfach kann die Welt manchmal sein... :o
Jepp sieht danach aus. Ich hab mir jetzt mal ein step down Modul bestellt, welches genug Saft hat um den ganzen Krempel zu versorgen.
Ich dachte immer usb muss 500ma bringen lt. Norm.
Im Land der Himbeeren ist das anscheinend anders ;)
Grüße
Matze
So hab gerade das step down modul eingebaut.
Ganz mutig sämtliche Nodes und gateway darüber versorgt. Sieht schonmal gut aus. An der weit entferntesten Stelle nach 30m Kabel immernoch 4,950 Volt. und auch relativ stabil. Minwert hatte ich 4,900V sollte passen!
Mit wieviel spannung laufen denn die Nanos noch zuverlässig?
Was aber komisch ist - laut log hatte ich seit heute morgen wieder einen Ausfall. Hab ich aber leider eben erst bemerkt als ich schon umgebaut hatte.
Ich werde auf jedenfall weiter beobachten / berichten!
Viele Grüße
Matze
Die Nanos laufen mit 8MHz (Deine haben bestimmt 16MHz) auch noch mit 1-2 Volt.
Der Max487 läuft soweit ich das noch richtig im Kopf habe, laut Hersteller, aber nur mit >=5V.
Zitat von: Ranseyer am 01 Dezember 2017, 14:45:10
Der Max487 läuft soweit ich das noch richtig im Kopf habe, laut Hersteller, aber nur mit >=5V.
Es gibt hier aber auch 3,3 V Typen, die heißen irgendwie MAX3847 oder so.
Gruß PeMue
Lohnt es sich dem max487 einen Kondensator zu spendieren? Ähnlich wie bei den funkmodulen oder ist das übertrieben?
Grüße
Matze
Das müsstest du testen. Theoretisch ist eh en Abblock-Kondensator gegen böse HF vorgesehen. (Auch auf meinen Platinen)
Streng genommen wäre also zu testen:
10-100uF Stützkondensator (Zeigt nur bei Spannungseinbrüchen Wirkung)
5-22pF Abblock-Kondensator (Zeigt nur Wirkung falls Störungen bestehen in deiner Gegend)
ZitatEs gibt hier aber auch 3,3 V Typen
Das finde ich spannend. Ist nur die Frage ob Pinkompatibel und der Preis... (die 487 kosten gerundet: gar nichts... :o)
ed: Ich habe durchaus vor der Entscheidung für den *487er nach Alternativen geforscht, die erschienen mir halt zu teuer. "Leider" gibt es ganz ganz viele Alternativen.
Hast du Erfahrung wie sich der 487 bei spannungseinbruch verhält?
Interessant ist wenn wirklich die Spannung einbricht und der 487 Nix macht wie mysensors reagiert.
Versucht das node weiter zu senden? Bzw. Bootet der 487 einfach wieder durch und funktioniert oder muss sich der Chip immer wie beim Boot am node registrieren?
Sprich einmal weg, bis zum Neustart weg.
Ps.: geht bei euch eigentlich der reboot Befehl über fhem? Funktioniert bei mir nicht!
Grüße
Matze
Zitat von: smoudo am 01 Dezember 2017, 17:29:53
Ps.: geht bei euch eigentlich der reboot Befehl über fhem? Funktioniert bei mir nicht!
Der reboot-Befehl funktioniert - aber nur, wenn einer der OTA-Bootloader installiert ist. Ist das nicht der Fall, hängt der Arduino wirklich, und zwar richtig ;) .
Genau. Da flackert alles nur. Bootloader habe ich mich noch nicht mit beschäftigt. Ist vielleicht auch einen Thread wert.
Grüße
Matze
Zitat von: smoudo am 01 Dezember 2017, 17:47:59
Ist vielleicht auch einen Thread wert.
Den gibt es indirekt schon. Aber: das bringt für RS485 gar nix, der bestehende ist nämlich nur für nRF. Der Bootloader macht dann einen speziellen Modus zur Ansteuerung des nRF auf...
Du kannst natürlich gerne einen OTA-Bootloader für RS485 bauen und die Anpassungen der FHEM-Module an Hauswart schicken, der freut sich bestimmt genauso wie die MySensors-Community weltweit 8) .
Klar, mach ich Sonntag früh zwischen Frühstück und Kirche ;)
Grüße
Matze
Ich hab mal mit Maxim gechattet, die sollten doch schneller wissen welche Pin Komptaiblem Chips es gibt... (Das mach ich wohl nie wieder... Oder es gibt noch andere Supporter ?)
Mein Zwischenstand komplett abweichend vom Support:
https://para.maximintegrated.com/en/results.mvp?fam=rs485&793=2.5%20to%205.5
Hm, der Link funktioniert nicht so ganz.
Daher hier mal 1-2 interesannte Typen:
MAX3430
MAX3072E (oder 75 / 78)
Wieder ein Ausfall, Gateway ist diesmal noch da(Startup complete, opened), alle nodes zur selben Zeit tot.
Edit: nachdem ich das Wasserzähler node neugestartet habe gingen alle anderen ohne mein Zutun auch wieder. Seltsame Geschichte!
Grüße
Matze
Ist es vielleicht ein Ansatz die nodes täglich neu zu booten?
Kann man da im sketch eine Zeitschleife für reboot einbauen?
Bzw. Wenn die kom. Wegfällt das node automatisch neu zu starten?
Grüße
Matze
Heute Abend wieder ein Ausfall. Diesmal nach reset des gaszählernode wieder ok.
Irgendwie werde ich nicht so ganz schlau aus dem ganzen. Werde jetzt ein paar kondensatoren
Am node Eingang platzieren um spannungsschwankungen ausschließen zu können.
Viele Grüße
Matze
Leider haben die Kondensatoren an den Nodes nichts gebracht. Hatte heute wieder 2 Ausfälle.
Istzustand:
5V Einspeißung am Gateway + USB Power von einem Nuc (habe testweise eine VM laufen)
5V Einspeißung am entferntesten Node. Alle anderen sind über Kabel verbunden. die beiden Nodes die immer aussteigen haben je einen 47uf Kondensator verpasst bekommen.
Nach einem reset der Node funktioniert wieder alles. Ansonsten sendet keine node readings.
Wenn das mit dem Host und der VM auch nicht sauber läuft, gehen mir langsam die Ideen aus. :(
Viele Grüße
Matze
Die 5V-Schienen sind aber nicht miteinander verbunden, oder?
Was du neben der 3-fach-Header-Sache noch versuchen könntest: Baudrate erhöhen. Mein Bus läuft mit 38400.
Gruß, Beta-User
Zumindest wird das Gateway einmal über usb und einmal über den step down verbunden.
Die 3 nodes laufen über ein Netzteil und die kondensatoren. Der bus wird logischerweise schon von 2 netzteilen versorgt. DiebWiderstände Vorne + hinten. Ist das ein Problem?
Wenn ich jedes node separat per usb versorge ist es doch nicht anders oder?
Bis jetzt läuft es auf der vm ganz anständig. Aussagen getraue ich mich mittlerweile erst nach 2 Wochen zu machen :D
Grüße
Matze
Hi,
prinzipiell immer GND überall verbinden (Außer in ganz speziellen Fällen)
Über das Buskabel kann man auch Sensoren mit Spannung versorgen. Aber dann sollte am Sensor nicht nochmals eingespeist werden.
Wenn du am Buskabel z.B. auf beiden Seiten 12V (oder 5V) einspeist, dann werden die 12V nie gleich wie die 12V an der anderen Seite sein, dadurch fliessen ungeplante Ströme die man nicht haben will...
ZitatZumindest wird das Gateway einmal über usb und einmal über den step down verbunden.
Wie genau meinst du das ?
Klar ist:
-Der USB Anschluss liefert nebenbei 5V an den Arduino.
-An meinen Gateways kann man auch eine "beliebige" externe Spannung einspeisen, diese sollte aber nur in Richtung des Buskabels verbunden sein.
Das mit den Widerständen irritiert mich auch etwas.
Optimal ist es (aus dem Kopf zitiert): 120 Ohm A-B am GW, am Bus-Ende dann nochmal die 120 für A-B und ca. 440Ohm-1kOhm pullup und -down.
Bei mir sind (bisher) alle GND verbunden bis auf das GW und auch die + 12V gehen an alle außer dem GW.
Das scheint jetzt (mit 440 Ohm) stabil zu laufen...
Am Gateway nur 120 Ohm? Kein pull-up/down?
Hab am beiden Enden die 120 Ohm + pull-up/down 390 Ohm.
Die zusätzliche Einspeisung am Gateway kommt bei mir zwecks zu wenig Spannung vom raspberry.
Werde ich wenn ich dauerhaft die vm nutze noch ändern.
Bei mir sind (nur am GW) noch die auf den Modulen verbauten 20k drauf, aber das ist eher "ferner liefen", und wenn ich wieder Probleme feststelle, fliegen die auch noch runter...
Irgendwo hatte ich doch einen link zur Widerstandsberechnung gepostet, ich find's nur grade nicht.
Jepp damit habe ich die Widerstände berechnet
Also auf http://www.alciro.org/tools/RS-485/RS485-resistor-termination-calculator.jsp finde ich 4 Widerstände: Ra, Rb und die beiden Pullup- bzw. Pulldowns...
Die beiden letzteren sind auch danach nur auf einer Seite! Bei Dembrowski steht nach meiner Erinnerung auch nichts anderes.
Danke für den Klasse Link.
PS: Auch das sollten wir uns noch 3-4 Mal reinziehen: https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss
Finde ich nachvollziehbar.
Danke für den Hinweis zu HM-Wired. Das ist vor allem deswegen interessant, weil dort als Grund für die nicht-standardkonforme Ausführung des Busabschlusses genannt wird, dass die HM-wired-Datenrate _zu niedrig_ sei!
Auf MySensors war zu lesen, dass RS485 erst ab 9.600 Baud läuft - das war der Grund, warum ich dann testweise mit 38.400 Baud ins Rennen gegangen bin (und das bis heute so belassen habe, weil es jedenfalls nicht schlechter zu sein schien als 9.600).
Ergo: entweder die Datenrate runternehmen und sich für das Widerstandsthema an HM-wired orientieren (hohe Widerstandswerte bis unendlich) oder eher niedrige/standardkonforme Werte nehmen bei höherer Datenrate...
Wäre für letzteres ;)
Jetzt lief das ganze schonmal besser. Seit gestern sfumktioniert die usb Durchreiche der virtuellen Maschine nicht mehr zuverlässig. Warum auch immer. Ich hoffe ein reboot erledigt das.
Frage:
Hat schonmal jemand über ein esp8266 zu rs485 Gateway nachgedacht/ realisiert?
Damit könnte man auch mehrere rs Kreise abbilden solange wlan da ist.
@ ranseyer können die Max 487 und 485 gemischt betrieben werden?
Viele Grüße
Matze
Gateway node habe ich ausgetauscht. Scheint ein Problem mit dem usb Controller gegeben zu haben.
Seitdem ist das Gateway wieder stabil da.
Baudrate hab ich bei der Gelegenheit angehoben auf 38400 und alle nodes auf Beta 2.2.0 geflasht.
Seit 10 Uhr läuft nur noch der gaszähler, Strom und Wasser senden erneut nicht mehr.
Ratlos >:(
Frohe Weihnachten
Matze
Wie sehen die Spannungen aus?
Dann: Mach mal bei allen den soh-count auf drei (letzte beta nehmen).
Kurz, da mobil
Spannung hab ich leider nicht gemessen im hängenden zustand ::)
Ist soh-count ein def im rs485 Header?
#define soh-count 3
EDIT: Habs gefunden, muss heißen:
#define MY_RS485_SOH_COUNT 3
macht es sinn ein: #define MY_TRANSPORT_WAIT_READY_MS xxx mit verschiedenen werten zu setzen damit die nodes nicht gleichzeitig senden?
Grüße
Matze
Ja, allerdings ist die Schreibweise anders.
#define MY_RS485_SOH_COUNT 3
[/size]Letzte beta-Aktualisierung...
ist umgeflasht. ich werde berichten :)
komisch ist: habe eben gerade beta 2.2.0 rc 2 genommen. in FHEM steht immer noch 2.2.0 rc1 ?!?
edit: nochmal neustart - 2.2.0 rc2 - ich gehe davon aus dass das gateway beim ersten start noch nicht da war.
Nochmal eine Verständnisfrage:
Die Usb Seite des gateways bleibt trotz erhöhen der busrate auf 115200 baud, richtig?
Zumindest kommt was brauchbares an.
Sorry für meine blöden Fragen, bin normal in einer anderen Branche unterwegs.
Aber lernwillig ;D
Korrekt !
PS: "geschlossene Fragen" wie die sind immer gut!)
Heute Morgen waren wieder 2 nodes tot.
Komischerweise funkte das letzte(Gas) im Bus noch während node
Strom und Wasser nichts mehr von sich gaben. Bus Spannung zwischen A und B
Ist 2V nach reset des Wasser nodes 0,2-0,3V, seitdem wieder funktionell
Was haltet ihr von einem wdt watchdog und reboot der node?
Ist zwar nicht die Lösung des Fehlers, sollte aber zumindest die
Probleme lösen?!?
Das ganze ist echt mysteriös, kommt mir aber leider in Teilen nicht unbekannt vor...
Das mit dem wdt _könnte_ helfen, allerdings bin ich mir nicht so sicher, ob ein watchdog wirklich zuverlässig erkennen kann, dass die Nodes tot sind - so richtig tot sind die nämlich vermutlich gar nicht.
Zur Erläuterung: ich habe mehrere Nodes, die nicht nur Sensorik beinhalten, sondern auch autonome Rektionen - Licht einschalten bei Bewegung usw.. Selbst bei gestörter Kommunikation (also keine aktualisierten Readings mehr von diesen Nodes) reagieren diese - jedenfalls eine gewisse Zeit lang (mind. mehrere Stunden) - noch so wie sie sollen. Die loop() läuft also noch (an den interrupts hängen bei 2/3 noch Zähler, die Auswertung der Bewegungsmelder läuft innerhalb der loop()). Sowas dürfte ein wdt nicht erkennen, oder (das ist so ziemlich das einzige, das ich noch nicht ausprobiert habe ::) )?
Meine Hypothese dazu war, dass altsoftserial sich nur bedingt verträgt mit anderen libs, die timings einhalten müssen (bei den "problematischen" Nodes sind jeweils noch mehrere 1wire-Busse angeschlossen). Daher nutzen jetzt die Nodes hw-serial, die auch DS18B20 abfragen sollen. Interessanterweise trat das Problem nicht auf, solange nur eine Node dran hing, obwohl die recht viele Werte zu übermitteln hatte. Erst, als Nr. 2 und 3 dazukamen, kam es zu solchen Effekten.
Nachdem ich noch ein paar individuelle Themen an einzelnen Nodes verändert hatte und die Widerstandswerte dann tatsächlich in etwa auf das errechnete Soll geändert, hat das auch über längere Zeit gut funktioniert - bis vor 2 Wochen eine weitere Node dazu kam und der Bus zwischen Node 4 und 5 einen weiteren Teilnehmer bekam... In dem Zusammenhang habe ich versucht, die AP-Dosen dann mal endlich zuzumachen usw.... Seitdem ist jetzt wieder der Wurm drin :( . Um was gesichertes sagen zu können, sollte ich aber den RS485-Baustein nochmal tauschen, kann sein, dass ich einen erwischt habe, der bekanntermaßen einen Hau hat (lag grad' so geschickt rum...)
So langsam werde ich dazu aber den Verdacht nicht mehr los, dass die MAX485-Module das eigentliche Problem sind. In welche Richtung, ist mir aber noch völlig unklar. Beim Verbau in die Dosen scheine ich jedenfalls auch Spannungsprobleme bei deren Versorgung verursacht zu haben.
Fragen:
- gibt es Anhaltspunkte für die Annahme, dass die MAX485-Teile isoliert mit einer Art overflow den Dienst einstellen?
- @Matze:
-- Kannst du die Module separat abziehen bzw. stromlos machen? (das habe ich bisher auch noch nicht versucht). Es wäre interessant zu wissen, ob die Kommunikation wieder läuft, ohne dass man den Arduino selbst neu anwirft.
-- Kannst du auch mal zwischendurch messen? Ich hatte den Eindruck, dass die A-B-Spannungswerte teilweise über Stunden kontinuierlich anwachsen können, bis dann schließlich die 2V erreicht sind und - außer beim Verursacher (?) nichts mehr geht.
Gruß, Beta-User
Jepp kann ich machen. Hab das ganze auch in AP Dosen, mit Wago Klemmen. Hab jetzt mal den Wachhund mit rein genommen. Bin mal auf die Wechselwirkungen gespannt. Die besagte altsoftlib, ist die standardmäßig in Verwendung? Bei mir laufen die nodes auf max487. Die Frage ist wie spannungsempfindöich sind die Teile? Hab vor die nodes ein 47uf geschraubt -ohne Erfolg-
Wenn das jetzt nicht läuft Test ich mal mit 3 separaten Stromkreisen.
Hast du die Standarte 485 auf dem pcb? Hab noch 5 davon da, falls du bedarf hast?
Sind die mischbar?!?
Ging schneller als erwartet, kurzer Check- alle nodes ohne readings :(
jetzt wirds freaky.
Als ich nachhause kam, blinkte auf den Nanos Strom und Wasser die LED "L" wie verrückt. Ein abziehen des Stroms von den nodes brachte den Bus nicht mehr zurück. Ein reset der Nodes bringt auch keine besserung - komplett strom weg auch nicht.
Nach kurzer Suche musste ich feststellen, dass das gateway nicht mehr auf "startup complete" steht sondern auf "connected"
Nach Neustart des Gateways selbes spiel. Keine Datenübertragung mehr. Kurz mal in der IDE seriell gecheckt - Kein Lebenszeichen des Gateways - was geht denn da ab?!?
Anscheinend wird der reboot vom bootloader nicht unterstützt?!? macht zumindest die selben faxen wie wenn ich über
fhem einen reboot schicke.
Also wieder alle zurückgeflasht ohne reboot :o
Ich habe jetzt jedem node separat ein 5V Netzteil verpasst. Wenns jetzt nicht klappt weiß ich auch nicht mehr.
Gibt es fürn Nano keinen anderen bootloader?
Nachdem auch die separate Spannungsversorgung keine BEsserung gebracht hat, habe ich jetzt nochmal den Nano des Wasserzählers ausgetauscht - die Hoffnung stirbt zuletzt ;)
Spannung war auf 1.8V nach reset des Wasserzähler Nodes wieder im Bereich 0.3V Die beiden anderen Nodes funktionierten zu dem Zeitpunkt noch. Werde bis heute nachmittag nochmal kontrollmessungen durchführen
Bis jetzt ist der Bus konstant auf 0,3V
Gerade nach Hause gekommen. Um ca. 18 Uhr das letzte Signal.
Diesmal war node 1 Stromzähler der Auslöser. 1.87V auf dem Bus.
Gibt es noch Lösungsansätze? Ich hab das Eindruckl mit höherer baudrate
Kommen die Fehler zügiger.
Das komische ist, das es auch mal fast 2 Wochen durchgelaufen ist und jetzt geht gar nichts mehr.
Mich würde mal die Meinung von Beta-User interessieren...
-ich hätte auf HW-Problem getippt...
-siehst Du das auch so ?
PS: An HW fällt mir ein:
-Gateway (Fake FTDI? Anderer Chip?)
-Sensor
-jeweils der Arduino
-jeweils der RS485 Chip (Fake, außerhalb der Spec, defekt)
-Versorgungs-Spannung
-Störsignale (kein Abblock-Kondensator verbaut)
-Bus (Kabel, Verbindungen, Widerstände
Das scheint mir doch recht konkret:
ZitatKein Lebenszeichen des Gateways
Würde sagen das Gateway muss immer reagieren. Egal was am Bus los war.
Aufbau:
Alles arduino nano mit ch340 seriell, aus verschiedenen chargen/Lieferanten.
1x Gateway, 3x Node.
Kabel sind 4*2*0,6mm2 geschirmt, Buslänge gesamt 25-30m.
Bus hardware sind die pcb mit den max487 von dir.
Jedes node hat momentan seine eigene 5V Spannung per Netzteil. Bzw. Gateway am Intel Nuc USB.
Am Gateway ist ein 2 m Kabel mit 120 Ohm widerstand.
Hinter der letzten node sind 0,2m Kabel mit 120 Ohm zwischen A und B sowie 390 Ohm zwischen A und 5V
Und B und GND
Die Störungen kamen bislang eher von den nodes. Gateway hatte ich jetzt einen Defekt des ch340. Der war dann zeitweise offline. Nano getauscht, seitdem läuft das Gateway sauber.
Mit keiner Reaktion war in dem Fall nur mit neuflashen zu handeln, das führe ich aber eher auf die Bastelei im sketch zurück. Wird mit der Bus Spannung eher nichts zu tun haben.
Was mir seit geraumer Zeit auch aufgefallen ist:
Ich konnte über fhem immer schön value11 setzen als korrekturwert der Stände.. Das geht auch nicht mehr, selbst wenn der Bus frisch resetet ist.
Zitat von: Ranseyer am 26 Dezember 2017, 23:11:23
Mich würde mal die Meinung von Beta-User interessieren...
-ich hätte auf HW-Problem getippt...
-siehst Du das auch so ?
Insgesamt sind diese ganzen Themen sehr unübersichtlich, in meinem Fall war/ist es auch ganz sicher so, dass es nicht "die" Ursache gab oder gibt - das fing an mit Platinen, die falsch beschriftet waren und so ;) und endet bei Wacklern in der Spannungsversorgung...
Debugging ist halt recht schwierig, weil es immer eine gewisse Zeit (Stunden bis wenige Tage) dauert, bis was auffällig wird.
Aber zu smudos Themen:
- Was das GW angeht, das plötzlich auf "open" stand, klang mir das auch sehr nach einem HW-Thema. Getippt hätte ich allerdings nicht auf den USB-Wandler, sondern auf einen gelöschten Flash-Speicher des Arduinos.
- Baud-Rate: einfach testen, wenn du glaubst, niedriger wäre besser. Wie gesagt, bei mir lief es über längere Zeit @38400 auch schon ohne Probleme, teilweise haben die Arduinos SOH-count 3 und Hardware-Serial (4 Nodes+GW, die Nodes alle am selben 12V-Strang). Bis ich das wieder (wegen der 5. Node, die im Moment ein eigenes 5V-NT hat) angefaßt hatte >:( ...
- Das Ansteigen der Spannung deutet m.E. immer darauf hin, dass eine Node spinnt - interessant ist es dann aber herauszufinden, was genau eigentlich die Ursache ist. Meistens scheint es so zu sein, dass ein reset dieser Node ausreichend ist, damit alles wieder funktioniert. Aber eine richtige Regel habe ich dahinter bisher auch nicht entdecken können, es ist oft dieselbe, aber eben nicht immer. Vorgestern habe ich z.B. auch so einen Fall gehabt (SOH-gepatchte HW-serial-Node mit einer Anzahl DS18B20) und dann nur mal das Modul abgezogen. Das hat nichts geholfen (Ursache also tendenziell auf dem Arduino, nicht beim Transceiver), daher restart: War wieder da, ist aber nach sehr kurzer Zeit wieder ausgefallen. Vermutete Ursache: Spannungsversorgung. Allerdings: es ist neben dem auf dem Pro Mini verbauten 12V-Wandler ein weiterer LMS1112 (?) mit Kondensatoren (fertiges Modul) verbaut. Das dürfte eigentlich nicht so schnell in die Knie gehen.
Jedenfalls: ist die Spannung bereits deutlich weg von 0V, muß jeder Transceiver-Baustein dann richtig "arbeiten", wenn er eine "1" loswerden will (-0,2V, wie bereits hier geschrieben (https://forum.fhem.de/index.php/topic,78778.msg713812.html#msg713812)). Könnte also auch sein, dass da zwei Transceiver-Bausteine gegeneinander arbeiten. Ich werde jedenfalls bei nächster Gelegenheit mind. den Baustein an der neuen Node tauschen (da ist aber irgendwo auch ein Wackler an der Spannungsversorgung, das muß ich mir "bei Tag" mal genauer ansehen, oder das kommt auch an die 12V...)
- Dass das mit dem value11 nicht klappt, ist auch seltsam. An sich hätte ich behauptet, dass die Kommunikation auf dem Bus klappt oder eben nicht. Aber es könnte tatsächlich so sein, dass nur "starke" Nodes (mit genügend Spannung) gegen irrlichternde Transceiver ankommen. Es könnte sein, dass das GW (Am Pi?) zu schwach ist (aber bei ca. 0V zwischen A+B sollte es in jedem Fall gehen). Aber wenn die Info vorher nie bei der Node angekommen war, ist diese verloren, das muß dann bei "durchlässiger" Busspannung wiederholt werden.
Ansonsten bin ich mit meinem Latein auch ziemlich am Ende. Was meinen Bus angeht, bin ich am überlegen, ob ich alle Transceiver-Bausteine austausche und wenn ja, gleich gegen MAX487 (würde aber massive Lötarbeiten bedeuten, das will ich eigentlich auch nicht so richtig...). Hat jemand Info, ob die (außer der # der potentiellen Teilnehmer auch sonst besser sind)? Mischen sollte gehen, wenn nicht mehr als 32 Teilnehmer, oder?
Gruß, Beta-User
Laut Daten Blatt von Maxim ist ein Mischbetriebder Max Chips möglich, unter der Vorraussetzung wie du schon schreibst das die Teilnehmerzalhl von 32 nicht überschritten wird.
Thx, dann werde ich wohl als erstes mal das GW auf Basis MAX487 angehen. (Lochraster, bin Groblöter...)
Was die Beschaltung angeht: irgendwas spezielles zu beachten? Ich würde schlicht die (reduzierte) Beschaltung der LC-Module kopieren, also 120Ohm A-B und dann an jeden Eingang 1kOhm, ggf. noch ein Kondensator für die Versorgungsspannung (Wert?). Bessere Vorschläge (ohne dass ich intensivst Schaltpläne studieren muß, die ich kaum verstehe)?
Habe dazu auch noch einen Pro Micro rumliegen (sollte auf ATMega32U4-Basis sein) . Hat mit dem jemand Erfahrung? Ich würde gerne:
- Hardware-Serial für RS485 nutzen (sollte ganz einfach gehen, indem ich serial1 für RS485 definiere)
- Dem Ding wieder eine "sprechende" USB-Kennung verpassen. Die CUL-firmware macht das ja mit diesem Prozessortyp über entsprechende defines, aber wenn ich das richtig verstanden habe, stecken diese Infos später dann im Bootloader. Klingt danach, als wäre das damit bei "normalen" Arduino-Sketches ein gesondertes Thema - was doof ist, weil ich nicht eine spezielle Board-Def erstellen will und jedes Mal aufpassen, dass ich jetzt das richtige Board einstelle oder versehentlich den "eigenen" Bootloader ganz lösche. Oder hat da jemand einen Tip? (ist prio 10, wird bis auf weiteres der einzige Pro Micro am Server sein. Es geht eher drum, einen "einsteigerfreundlichen" Weg auszuprobieren, wenn ich schon mal dabei bin).
Gruß, Beta-User
Die proMicros die ich bis jetzt verwendet habe sind in meinen NanoCuls verbaut. Die melden als "usb-busware.de_promicroCUL868-if00", scheint also als könne man denen eine eigene ID mitgeben. Probleme hatte ich beim ersten mal flashen, da hab ich dann den ganzen Bootloader weggeschossen :P. Kann man dann aber problemlos wieder per ICSP zurückflashen. Hardware-Serial wäre bezüglich Stabilität sehr interesant.
Viele Grüße
Brasletti
Zitat von: Beta-User am 28 Dezember 2017, 14:15:43
(Lochraster, bin Groblöter...)
Wenn es sauber werden soll (Stabilität), kann ich dir auch ne Platine pinseln. (Pro Micro habe ich für diesen Zweck noch nicht genutzt)
Kondensator am Eingang würde ich 4,7-100uF verbauen (=10 oder 47), parallel 22pf oder so am MAX
Zitat von: Brasletti am 28 Dezember 2017, 14:37:11
Hardware-Serial wäre bezüglich Stabilität sehr interesant.
U.a. deswegen hatte ich die damals gekauft - und eben der Option, ggf. "direkt", also ohne FTDI-Tool eine eigene ID vergeben zu können. Dass das grundsätzlich geht, ist klar, interessant ist halt, wo es reinkompiliert wird.
Das Problem mit dem Bootloader besteht darin, dass die IDE wissen muss, wie groß der ist (resp. der bereits genutzte Speicher), sonst gibt's Probleme. Das erfährt sie aus der Board-Def - die muß also zum tatsächlich verwendeten Bootloader passen, sonst braucht man wirklich den SPI-Zugang, um alles wieder in einen definierten Zustand zurückzuführen - das wäre mir dann noch zu viel, dann hat er halt den "Standard-Namen", wenn ein willkürlich gesetztes
#define BOARD_ID_STR "RS485_MySensors_ProMicro_GW" nicht klappen sollte...
Aber wenn, wäre das schon super easy, auch für Neueinsteiger ins Thema, zumal die ProMicros günstiger zu haben sind als gefakte FTDI-Nanos ;) .
@Ranseyer:
Danke für's Angebot. Wenn das mit HW serial und der Umbenamsung klappt würde ich sagen: Lohnt sich, da dann auch für andere interessant (vermute ich jedenfalls).
Ich bau's bei Gelegenheit auf Breadboard (habe die Lochrasterfreundliche Variante der MAX487 daliegen) auf, dann sehen wir weiter.
Ansonsten sollte ich evtl. einfach mal eine Ladung von der Hühnerfutter-Variante besorgen und schlicht die Module umlöten, geht vermutlich an dem Ende dann schneller...
Im MySensors Forum liest man nicht sehr viel über die Verwendung des ATMega32U4 bzw. ProMicro. Manche berichten über Probleme bei der Umschaltung der USB Schnittstelle vom Bootloader zum Eigenlichten Sketch. Evtl gibt es ja die Möglichkeit wie beim Nanocul den Bootloader komplett zu ersetzen. Eine andere Möglichkeit wäre es auch mal mit einem ESP8266 zu testen, der hat ja auch zwei Serielle Schnittstellen. bzw. halt eine übrige wenn man man einen Wemos D1 Mini zum testen verwendet.
Viele Grüße
Brasletti
Die Variante mit dem Pro Micro würde ich auch nachbauen. Die finde ich prinzipiell genial. Nichts zu viel. Nichts zu wenig.
Was mir für Smoudo noch eingefallen ist: Man sollte für a+b ja einen verdrillten Draht nehmen. Wenn also Pin 1-4 der Reihe nach an ein Kabel angelossen werden, wäre das falsch.
Pin 1+2 verdrallt wäre dann z.B. GND und B. (Ich hab jetzt die Belegung nicht im Kopf)
Ich nehm da meistens Patchkabel. Davon ein Pärchen als Masse, eins als Pluszuleitung und eben ein Pärchen als Bus. Was ich auch manchmal lese ist die Verwendung eines Kondensators an den Nodes um Störungen in der Spannungsversorgung zu glätten.
Den ProMicro kann man doch auch so flashen dass der original Bootloader weg ist, oder? So dass die Serielle Anbindung auch ohne Unterbrechung zur Verfügung steht.
Habe bereits die verdrillten Adern genommen. Einzig etwas zum entstören am max487 ist nicht verbaut. Kondensatoren zwischen 4V und gnd am node sind jeweils mit 47uf vorhanden. Wobei ich spannungsprobleme fast ausschließen würde, nachdem jetzt alles separat ein NT hat. Die einzigen Einflüsse die ich mir vorstellen könnte, sind irgendwelche Magnetfelder im heizraum. Wobei das Kabel einen aluschirm hat, sollte theoretisch nichts machen.
Ich habe mir jetzt noch 2 nanos mit Ftdi chip bestellt zum testen, ansonsten werd ich die zählerschiene wohl mit einem esp abfackeln und den rs Bus eher Richtung Garage weiterprobieren. Wobei ich jetzt testweise mit868mhz gute Durchdringung realisieren konnte.
Ups... war im falschen Thread