borg

Wir haben das Temperature IR 2.0 hier ausgiebig unter den unterschiedlichsten Bedingungen getestet. Ich konnte nie so einen Fehler erzeugen . Gibt es irgendetwas womit du den Fehler reproduzieren kannst? Oder tritt es immer einfach so nach einiger Zeit auf?

Statt if (identifier = 119) { musst du if (identifier == 119) { verwenden.

Ja, ich wüsste nicht warum das nicht funktionieren sollte.

Das ist leider nicht möglich. Wir lauschen immer mit einer festen Bitrate, diese ist aber von Typ zu Typ unterschiedlich.

How do you detect the button press? Do you use the internal pull-ups from the IO-4 and the button shorts to ground? If that is the case, you might want to add an additional pull-up (perhaps 1k or similar). The internal processor pull-up is specified to be somewhere between 100k and 400k, which might be to little resistance for the interference from the pump?

Du musst beide Ifs in einen Callback packen. Dein zweiter ".on"-Aufruf überschreibt den ersten.

Support im Master Brick gibt es seit 2.4.4, im Brick Viewer seit 2.3.13. Ich würde aber auf jeden Fall empfehlen auf die neusten Versionen zu aktualisieren!

Schick einfach eine Email an die info@tinkerforge.com mit deiner Bestellnummer, wir tauschen den Sensor dann aus.

Alles auf dem neusten Stand? Brick Viewer, Master Brick Firmware?

The "Internet of Thinkgs enclosure" is now compatible to the Outdoor Weather Bricklet . We put in some more mounting holes in the bottom, the holes in the front fit without changes. https://www.tinkerforge.com/en/shop/cases/internet-of-things-case.html I still have to make some updated photos.

Da können wir nichts dran ändern, Typ A ist sozusagen rückwärtskompatibel zu Typ C, aber je nachdem was geschickt wird nicht umgekehrt. Also rein analog die gesendeten Daten sind kompatibel, die Interpretation ist anders.

So, es gibt jetzt Firmware Version 2.0.1. Ich mache jetzt in der Tat eine Überabtastung der Daten und erlaube bis zu ~25% Unterschiede in Bitrate. In meinen Tests funktioniert das jetzt erheblich besser. Ich kann jetzt auch mit dem alten Remote Switch Bricklet das neue Remote Switch Bricklet 2.0 schalten. Bei Typ B wenn man alles auf 0 stellt (address, unit) kommt es schonmal öfter zu falschen Messungen. Rein technisch führt das dazu das im ganzen Bitstream das gleiche Pattern versendet wird und die Sync-Bits sehen dem Pattern sehr ähnlich. Dadurch bekommt das Bricklet manchmal einen Versatz rein. Selbst als Mensch ist das aber schwierig zu interpretieren. Die "address" wird ja von der Fernbedienung zufällig vergeben, daher sollte das mit einer echten Fernbedienung eigentlich nie auftreten. @insidERR: Wir schicken dir deinen Aufbau heute zurück (mit neuesten Firmwares drauf geflasht und getestet). Vielen Dank für das zusenden!

Firmware: NFC Bricklet 2.0.1 Add function for global maximum timeout to API Use RequestTagIDError state if no tag has been found after timeout Download: NFC Firmware: Remote Switch Bricklet 2.0 2.0.1 Digitize 2x oversampled input data in a fuzzy-manner to allow for bit-rate differences between remotes Use passive level 0 as expected by RFM69 IC Download: Remote Switch 2.0

Firmware: NFC Bricklet 2.0.1 Funktion zur Einstellung eines globalen Timeouts zur API hinzugefügt Nutze RequestTagIDError falls es einen Timeout beim suchen eines Tags gibt Download: NFC Firmware: Remote Switch Bricklet 2.0 2.0.1 Nutze Oversampling und "Fuzzy-Matching" zum digitalisieren der Daten. Dadurch können wir Bitratenunterschiede zwischen Fernbedienungen besser behandeln. Nutze Passiv-Level 0 für SPI, wie vom RFM69 IC erwartet Download: Remote Switch 2.0

Einen Hinweis gibt es übrigens auf der Shop-Seite. Bei jedem Bricklet mit neuem Stecker steht der Hinweis:

Du musst da immer Differenzen bilden. Beispiel: Du fragst einmal pro Stunde Werte ab. Dabei speicherst du immer den Wert der letzten Stunde (x_alt). Wenn du jetzt einen neuen Wert holst (x_neu) kannst du über die Formal x_neu-x_alt bestimmen wie viel mm Regen in diesem Zeitraum gefallen ist . Danach dann x_alt=x_neu setzen und nächste Stunde das gleiche, usw.

Die UID bei Bricks ist fest in Hardware und nicht änderbar.

Die Wetterstationen senden exakt die Daten die es per Getter gibt + die ID. Alternativvorschlag: Wenn eine ID verschwindet und danach eine neue auftaucht könnte deine Software einfach die alte ID durch die neue Ersetzen.

Die Wetterstation vergibt sich selbst eine zufällige ID bei Einlage der Batterie. Wenn die ID bereits vergeben ist musst du die Batterie rausnehmen und wieder reinlegen. Die ID wird spätestens nach 45 Sekunden "gelöscht" (wenn der Sender versucht Daten zu senden). Wir haben für das Outdoor Weather Bricklet extra ein Empfägermodul genommen welches auf die exakte Frequenz der Wetterstation ausgelegt ist, sollte also eigentlich guten Empfang haben. Eine einfache Möglichkeit die Wetterstation zuzuweisen ist es, ein Programm zu schreiben welches auf Knopfdruck o.ä. die IDs abfragt bis eine neue hinzu kommt. Diese ID ist dann eure Wetterstation. Dann könnt ihr den Knopf drücken und danach in Ruhe die Batterie einlegen. In eher "ländlichen" Gegenden wo die Wahrscheinlichkeit gering ist das es eine zweite Wetterstation gibt kann man natürlich auch einfach immer die eine ID nehmen die gefunden wird .

Tja, wir nutzen ja den RFM69 auf dem Remote Switch Bricklet. Der kann direkt die Daten digitalisieren und wir lesen sie per SPI aus. Dafür gebe ich die Frequenz an (433MHz) und eine Bitrate damit er es digitalisieren kann. Das Problem was wir hier gerade sehen ist denke ich, das die Bitraten ganz schön Unterschiedlich sind von Fernbedienung zu Fernbedienung (die Frequenz passt immer). Das passiert auf jeden Fall bei der Bricklet zu Bricklet Kommunikation hier. Wir nutzen für Typ C z.B. 319us pro Taktzyklus zum Senden (hab ich so per Trial-and-Error als besten Wert bestimmt) während ich (auch per Trial-and-Error) zum Empfangen 356us pro Taktzyklus bestimmt hatte. Das ist bereits soweit auseinander, dass der RFM69 da nicht mehr mit klar kommt nach ein paar Repeats. Die einzige Möglichkeit die ich da aktuell sehe ist das extrem überabzutasten. D.h. ich lese mit einem Taktzyklus von 30us (anstatt der ~300us die es wirklich sind) und kann das dann "analog" interpretieren und z.B. eine Bitrate zwischen 270us und 330us erlauben. Auf die Schnelle konnte ich im Datenblatt keine Spezifikation dazu finden ob ich der RFM69 so hohe Bitraten auch wirklich digitalisieren kann, muss ich dann testen. Ist auf jeden Fall keine 5-Minuten-Aufgabe, ich melde mich wieder wenn ich da mehr Infos habe.

Ich würde erwarten das 15m eigentlich funktionieren sollte. Du könntest schauen das die Antenne in Richtung Sensor zeigt (also nicht mit der Spitze, sondern mit der Seite der Antenne). Funk ist da ja manchmal ganz verrückt und eine kleine Änderung hat da eine große Wirkung.

Das kann ich nicht reproduzieren, bei mir funktioniert das. Bei Typ A kriege ich jedes Repeat mit, ohne Ausnahme. Bei Typ B sehe ich aus irgendwelchen Gründen nur so ~3/4 der Repeats die ich Sende. Bei Typ C noch weniger als bei Typ B. Ich gucke mir da mal an wo das Timing auseinander Läuft, das kann ich ja schonmal fixen. insidERR hat uns jetzt seine Fernbedienung zugeschickt, die bringe ich dann auch zum laufen. Ich hab hier eine Kiste mit gut 15 unterschiedlichen Steckdosen/Fernbedienungen liegen die ich getestet hab. Da gibt es anscheinend immer noch mehr Varianten... Da wirste echt bekloppt bei .

Der Sensor sollte ca alle 45 Sekunden Daten schicken. Wenn du den Getter nutzt gibt es den "last_change" Parameter der dir sagt wann das letzte mal Daten empfangen wurde. Kannst du den vielleicht mit plotten um zu sehen ob du in der Zeit wo sich der Wert nicht ändert keine Daten empfängst?

Mh, ich dachte ich hätte so eine Fernbedienung auch getestet, wahrscheinlich gibt es da einfach noch mehr Varianten als wir da haben. Das Bricklet versucht ja schon das Protokoll wirklich zu verstehen und vergleicht nicht einfach mit Aufzeichnungen.

Das ist eine gute Frage, das hab ich noch gar nicht ausprobiert . Ich kann gerade nicht sehen warum das nicht funktionieren sollte. An und für sich nutzen wir ja die gleichen Timings für das Senden und das Empfangen, daher wundert mich das gerade schon. Gucke ich mir auf jeden Fall an, vielleicht können wir ja das insidERR Problem damit auch fixen .