AskSin++ Library

Begonnen von papa, 08 September 2016, 11:11:25

Vorheriges Thema - Nächstes Thema

Wzut

11,12,& 13 kannst du nicht ändern , siehe Datenblatt des ATMega328. Einzig CS auf Pin 10 kannst du bedenklos umlegen.
D.h. die interne LED auf Pin 13 ist für dich verloren/wertlos , da hatten die Arduino Designer kein glückliches Händchen :)
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

papa

Zitat von: Wzut am 18 März 2018, 18:15:02
hmm laut https://github.com/kc-GitHub/Wettersensor/tree/master/Contrib/FHEM -> add lazy config option , sollte also für F101 und F102 nichts Neues sein.
BIDI habe auf WKMEUP geändert, leider ohne Erfolg.
Da es bei anderen Geräten aus papas Baukasten geht sollte FHEM das nicht unbekannt sein.  Ist für mich aber nicht tragisch da ich z.Z. dafür keinen Einsatzfall habe,   

Mach mal beide -> BIDI|WKMEUP
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

jp112sdl

Hat schon mal jemand das Phänomen beobachtet, dass ein Arduino/CC1101 auf Dauersendung war?

Ist mir nun schon ein zweites Mal passiert...  :-[
In der ganzen Bude ging nix (Funkgesteuertes) mehr.
Hab zum Glück nen SDR und konnte den Störer schnell ausfindig machen.
Ein nachgebauter WDS 10 TH O.

Batterien kurz raus - wieder rein. Nun geht wieder alles.

papa

Zitat von: jp112sdl am 18 März 2018, 20:05:45
Hat schon mal jemand das Phänomen beobachtet, dass ein Arduino/CC1101 auf Dauersendung war?

Ist mir nun schon ein zweites Mal passiert...  :-[
In der ganzen Bude ging nix (Funkgesteuertes) mehr.
Hab zum Glück nen SDR und konnte den Störer schnell ausfindig machen.
Ein nachgebauter WDS 10 TH O.

Batterien kurz raus - wieder rein. Nun geht wieder alles.

Hm - ich hatte mal ne Fernbedienung, die auf Dauersenden war. Aber ich denke da ist das Long-Press-Problem bei nicht vorhandenen Peer Schuld gewesen. Das kann aber bei WDS nicht sein.
Hast Du irgendwelche Logs ? Was wurde denn gesendet ?
BananaPi + CUL868 + CUL433 + HM-UART + 1Wire

jp112sdl

Zitat von: papa am 18 März 2018, 20:14:19
Hast Du irgendwelche Logs ? Was wurde denn gesendet ?

Hab ich leider nicht, da das Ding autark im Keller hängt.

Die CCU sagte mir "Kommunikationsstörung" zu so ziemlich allen meinen Geräten.
Hatte ich vor ein paar Wochen erst... Daraufhin hab ich mir für 13 EUR so nen DVB-T-Stick geholt, den man auch als SDR missbrauchen kann.
Mit CubicSDR habe ich dann einen Dauersender gesehen und bin (ohne Antenne!) der Signalquelle entgegengegangen.
Zu hören war währenddessen ein "Dauerquietschen", wie man es von FSK kennt. Also es war nicht nur ein Träger aufgetastet, sondern es muss auch permanent ein Datenstrom gesendet worden sein.

Ein ähnliches Verhalten hab ich mal in der HomeMatic-Community von den Fensterkontakten gelesen.

Daher hatte ich nun weniger den Sketch/Arduino in Verdacht - viel mehr den CC1101.

Sehr seltsam - ich beobachte das mal weiter.

Tom Major

Zitat@Tom Major , ich habe gerade deinen HB_UNI-Sensor1 auf dem Steckbrett laufen, ich habe lediglich deine Device Model F301 in F101 geändert damit es mit  der HMConfig_SenTHPL.pm zusammen passt. An Readings bekomme ich jetzt schon mal

ok, wenn FHEM lazyconfig unterstüzt ist das geklärt.
Hast Du gecheckt ob in deinem HMConfig_SenTHPL.pm bei F101 das steht
rxt => 'l:w:c:f'

Ausserdem:
ZitatLazyConfig
Kommandos in der Queue werden bearbeitet, wenn eine Aktion vom Device ausgeht. So zum Beispiel ein Tastendruck bei einer Fernbedienung. Dieser mode wird von CUL/CUNO nicht unterstützt. FHEM ignoriert diese Option automatisch und wartet i.A. auf ein Config.

Kann es das sein (CUL/CUNO)?
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat11,12,& 13 kannst du nicht ändern , siehe Datenblatt des ATMega328. Einzig CS auf Pin 10 kannst du bedenklos umlegen.
D.h. die interne LED auf Pin 13 ist für dich verloren/wertlos , da hatten die Arduino Designer kein glückliches Händchen :)

Eine Möglichkeit für Fortgeschrittene wäre noch, in papa's Radio.h statt HW-SPI eine SW-SPI mit anderen Pins einzubauen, aber ich bezweifele mal das die LED an Pin 13 den Aufwand wert ist  ;)
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

cactus-online

Zitat von: Tom Major am 19 März 2018, 00:31:15
Eine Möglichkeit für Fortgeschrittene wäre noch, in papa's Radio.h statt HW-SPI eine SW-SPI mit anderen Pins einzubauen, aber ich bezweifele mal das die LED an Pin 13 den Aufwand wert ist  ;)

Ganz sicher nicht. Da ist es besser, die LED auszulöten (wegen des unnötigen Stromverbrauches). Aber grundsätzlich bräuchte man dann ja eigentlich die Pins in der Typedef dann gar nicht. Egal, es ist halt wie es ist. Danke für die Infos, dann habe ich wenigstens verstanden, warum das so ist.

Tom Major

Zitat von: cactus-online am 19 März 2018, 08:56:33
Ganz sicher nicht. Da ist es besser, die LED auszulöten (wegen des unnötigen Stromverbrauches).

Kenne Dein HW setup nicht, aber bei meinem Pro Mini hat die LED an Pin 13 keinen Einfluss da sie ja im sleep aus ist. Erreiche ca. 4uA im sleep mit LED. Bild der HW ist ein paar Seiten vorher zu sehen. Nur den LDO und die Power LED habe ich ausgelötet.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Tom Major

Zitat von: jp112sdl am 18 März 2018, 20:58:41
Zu hören war währenddessen ein "Dauerquietschen", wie man es von FSK kennt. Also es war nicht nur ein Träger aufgetastet, sondern es muss auch permanent ein Datenstrom gesendet worden sein.
Ein ähnliches Verhalten hab ich mal in der HomeMatic-Community von den Fensterkontakten gelesen.
Daher hatte ich nun weniger den Sketch/Arduino in Verdacht - viel mehr den CC1101.
Sehr seltsam - ich beobachte das mal weiter.

Hmm, das klingt nicht gut.
Falls es noch einmal auftritt bei dem Selbstbau WDS 10 TH O, könntest Du hingehen und mit dem Multimeter messen ob chip select des CC1101 auf low oder high liegt? Ausserdem messen ob man an SCK diesen Dauer-Datenstrom sieht (Multimeter müsste ca. VBat/2 anzeigen, besser wäre natürlich ein Oszi, aber für ersten Test reicht auch Multimeter denke ich).
Um einzugrenzen ob es an der sketch SW oder intern am CC1101 liegt.
Man könnte ja dann über einen watchdog nachdenken, hat aber nur Sinn wenn der Dauer Senden Befehl von ausserhalb des CC1101 kommen würde.
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Wzut

Zitat von: papa am 18 März 2018, 19:49:14
Mach mal beide -> BIDI|WKMEUP
Bingo, so scheint es zu klappen. regSet lowBatLimitTHPL 1.1 hat dann CMDs_pending zur Folge
Bei der nächsten Übertragung der Sensorwerte konnte ich in der seriellen Konsole sehen : Config Changed  List 0 , lowBatLimitTHPL : 11
und CMDs done. set getConfig , wieder CMDs_pending , nach der nächsten Übertragung und CMDs done liefert auch get regList den neuen Wert.

Um nun den Sketch von Tom Major als echten Ersatz für den Unisensor benutzen zu können müsste nur noch geklärt werden wie man den Wert für die Höhe zum Sensor überträgt, ( das ist wohl z.Z. nicht vorgesehen ) bzw. wie setzt man von FHEM aus das neue Register für den Sendeintervall.   

Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tom Major

Zitat von: Wzut am 19 März 2018, 17:35:09
Bingo, so scheint es zu klappen. regSet lowBatLimitTHPL 1.1 hat dann CMDs_pending zur Folge
Bei der nächsten Übertragung der Sensorwerte konnte ich in der seriellen Konsole sehen : Config Changed  List 0 , lowBatLimitTHPL : 11
und CMDs done. set getConfig , wieder CMDs_pending , nach der nächsten Übertragung und CMDs done liefert auch get regList den neuen Wert.

Um nun den Sketch von Tom Major als echten Ersatz für den Unisensor benutzen zu können müsste nur noch geklärt werden wie man den Wert für die Höhe zum Sensor überträgt, ( das ist wohl z.Z. nicht vorgesehen ) bzw. wie setzt man von FHEM aus das neue Register für den Sendeintervall.

Freut mich dass es jetzt auch mit FHEM geht.
Höhe einstellen ist vorgesehen, tatsächlich bin ich gerade dabei den BME280 zu integrieren, wenn der läuft mach ich auch die Höhe, wird in den nächsten Tagen passieren..
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

Wzut

#762
Zitat von: Tom Major am 19 März 2018, 19:21:34
Freut mich dass es jetzt auch mit FHEM geht.
naja so richtig wollen die beiden noch nicht mit einander ... Ich habe mir jetzt mal die übertragenden Werte genau angeschaut :
1. temperature scheint zu passen
2. payload 0 & 1 sind bei dir 16 Bit Luftdruck , payload 0 wird beim Typ F101 allerdings als  8 Bit humidity ausgewertet
3. payload 1 & 2 sind dann in der Auswertung  die 16 Bit Luftdruck
danach kommt nichts mehr ( habe die Message Länge auch schon erhöht )
die  HMConfig_SenTHPL.pm zerlegt die Msg so :
my ($dTempBat, $humidity, $pressure, $luminosity, $batVoltage) = map{hex($_)} unpack ('A4A2A4A8A4', $msgData);
D.h. $dTempBat, $humidity, $pressure passen mit meinem Versuch zusammen , allerdings fehlen die letzten beiden.
Maintainer der Module: MAX, MPD, UbiquitiMP, UbiquitiOut, SIP, BEOK, readingsWatcher

Tom Major

ja, das FHEM Modul war noch eine Baustelle. Habe das originale so modifiziert dass es zu meiner payload aus dem Universalsensor passen müsste und erstmalig bei mir eingecheckt, schau es Dir mal an, im Ordner FHEM:
https://github.com/TomMajor/AskSinPP_Examples/tree/master/HB-UNI-Sensor1
Früher: FHEM 5.x
Jetzt: RaspberryMatic / ioBroker

andirs

Zitat von: Tom Major am 19 März 2018, 13:46:21
Kenne Dein HW setup nicht, aber bei meinem Pro Mini hat die LED an Pin 13 keinen Einfluss da sie ja im sleep aus ist. Erreiche ca. 4uA im sleep mit LED. Bild der HW ist ein paar Seiten vorher zu sehen. Nur den LDO und die Power LED habe ich ausgelötet.

Gelten die 4uA für den Ardunio alleine oder ist da der Verbrauch des CC1101 schon mit eingerechnet?
Schickt die Lib den CC1011 normalerweise schlafen? Ich frage daher weil ich auch etwa 4uA im sleep alleine für den Arduino erreiche.
Wenn der CC1101 angeschlossen ist habe ich in etwa 1,5 mA. Ich hab schon überlegt alle Sensoren und das Funkmodul während des sleeps von der Versorgungsspannung zu trennen...