Sekündliches Senden von Daten?

[MichaelAnders]

Moin,

Ich habe mir das hm-wds40-th-i-bme280 Projekt geschnappt und etwas angepaßt (siehe Anhang: bme280 auskommentiert, es wird jetzt immer eine hard-coded Temp/Humid gesendet). Ich konnte den Sensor auch mittels direkter Verknüpfung mit den zwei Thermostaten koppeln - perfekt also (für's erste)!

Aber: Ich sehe das gleiche Verhalten welches ich auch bei dem HM Uni Sensor Projekt: jede Sekunde sendet der Arduino Steht sowohl im Serial monitor und auch in den /var/log/messages auf dem rasperrymatic.

Dabei steht doch recht deutlich im Code:

Code: Alles auswählen

//seconds between sending messages
#define MSG_INTERVAL 180

Leider fehlt mir etwas Doku um zu verstehen wie asksin++ intern funktioniert (gibt's da eine Dev Doku?), aber so kann es doch nicht richtig sein?

[TomMajor]

Aber: Ich sehe das gleiche Verhalten welches ich auch bei dem HM Uni Sensor Projekt: jede Sekunde sendet der Arduino Steht sowohl im Serial monitor und auch in den /var/log/messages auf dem rasperrymatic.

Meinst du den HB-UNI-Sensor1?
Der sollte sich im Originalzustand an das eingestellte Update Intervall halten, was anderes ist mir nicht bekannt.

[jp112sdl]

Reboot Schleife?

Irgendwas mit dem Takt falsch?

[MichaelAnders]

Ich habe jetzt den Sketch in den ersten Post hochgeladen, hatte ich vergessen Kann ja vielleicht mal jemand ausprobieren ob es damit reproduzierbar wird?

Meinst du den HB-UNI-Sensor1?
Der sollte sich im Originalzustand an das eingestellte Update Intervall halten, was anderes ist mir nicht bekannt.

Ich meine den HB-UNI-Sen-Temp-DS18B20, damit hatte ich vorher rumgespielt.

Reboot Schleife?

Nein. Ich sehe das hier fortlaufend in den Logs, jede Sekunde kommt wird gelogged:

Code: Alles auswählen

Measure...
<- 0C B2 86 70 345681 000000 00 DC 23  - 10760213
Measure...
<- 0C B3 86 70 345681 000000 00 DC 23  - 10760268
Measure...
<- 0C B4 86 70 345681 000000 00 DC 23  - 10760325
iVcc: 4940
Measure...
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10760384
waitAck: 00
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10761027
waitAck: 00
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10761670
waitAck: 00
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10762313
waitAck: 00
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10762956
waitAck: 00
<- 0C B5 A2 70 345681 3C48D2 00 DC 23  - 10763599
waitAck: 00
<- 0C B5 A2 70 345681 3C49ED 00 DC 23  - 10764243

Ich arbeite mit asksin++ ja erst seit kurzem, von daher bin ich auf dem aktuellen Codestand...

Und mein Sketch ist ja

Irgendwas mit dem Takt falsch?

Wie kann ich das rausfinden? Ist ein normaler Arduino Nano & CC1101 - zusammengelötet gekauft, sowas löten ist nichts für mich

[jp112sdl]

Nano

Wirklich ein Nano?

[MichaelAnders]

Nano

Wirklich ein Nano?

Steht drauf, wird so programmiert und sieht aus wie der hier (Beschriftung leicht anders): https://external-content.duckduckgo.com ... f=1&nofb=1

[stan23]

Der Arduino Nano hat zwar auch einen ATmega328p drauf, wird aber mit 16 MHz und dadurch 5 V betrieben.

Das erklärt zwar auf den ersten Blick nicht warum jede Sekunde gesendet wird, aber die 5V sind zu hoch für das Funkmodul und machen es irgendwann kaputt.

Wenn du den Nano allerdings mit 3,3 V betreibst, ist das Funkmodul nicht gefährdet, aber du übertaktest den ATmega. Dann können die komischsten Sachen passieren...

[jp112sdl]

Ja, beim Nano bin ich auch raus.
16 MHz Reso und mit 8Mhz geflasht evtl?
Hmm...
In meinen Projekten verweise ich immer auf den 3.3V Pro Mini mit 8Mhz. Nicht ohne Grund.

[MichaelAnders]

Der Arduino Nano hat zwar auch einen ATmega328p drauf, wird aber mit 16 MHz und dadurch 5 V betrieben.

Das erklärt zwar auf den ersten Blick nicht warum jede Sekunde gesendet wird, aber die 5V sind zu hoch für das Funkmodul und machen es irgendwann kaputt.

Wenn du den Nano allerdings mit 3,3 V betreibst, ist das Funkmodul nicht gefährdet, aber du übertaktest den ATmega. Dann können die komischsten Sachen passieren...

Der Nano bekommt Strom via USB, sollten also 5V sein hätte ich gedacht? Und einer von meinen beiden scheint auf einer weiteren Platine vor dem CC1101 einen Spannungswandler zu haben (sieht jedenfalls stark danach aus).

Ja, beim Nano bin ich auch raus.
16 MHz Reso und mit 8Mhz geflasht evtl?
Hmm...
In meinen Projekten verweise ich immer auf den 3.3V Pro Mini mit 8Mhz. Nicht ohne Grund.

Ich löte sowas nicht, ist nicht mein Ding. Kann ich nicht und will ich auch nicht müssen Daher hatte ich mir was über Amazon und Ebay bestellt. Falls jemand einen Verkäufer kennt der "gutes Zeug" verkauft - nehme ich gerne!

Und geflasht habe ich nur die Sketche, mehr nicht?

Ein "_delay_ms(5000);" macht er absolut richtig. "F_CPU" zeigt mit 16 MHz an. Alles sehr merkwürdig...

Habe ein "radino32 CC1101" gefunden. Sieht interessant aus, hätte auch schön viel Speicher (da ginge wohl WLAN & MQTT mit rein) - aber das ist ein STM32L1 und der funktioniert so nicht (hab damit eben etwas rumgehacked, aber jetzt reicht es).

Also dann vielleicht doch einfach den Code um eigenes Timing erweitern damit er wirklich nur alle 30 Minuten was sendet... oder wenn sich was geändert hat.

[jp112sdl]

Also dann vielleicht doch einfach den Code um eigenes Timing erweitern damit er wirklich nur alle 30 Minuten was sendet oder wenn sich was geändert hat.

Na dann mach mal.

Sofern das innerhalb das des Zeitraums passiert, in der die CCU das nächste Telegramm erwartet - sonst erhältst du einen "Kommunikation gestört" Meldung.
Beim HB-UNI-Sen-Temp-DS18B20 wären das 1200 Sekunden.