Hi,
Ich habe mir vor ein paar Jahren einen UP 8Fach Fensterkontaktsensor auf Panstamp NRG Basis gebaut, Kann man bis zu 4 Fenster anschließen. Funktioniert so gut das ich jetzt weitere brauche. Dummerweise gibts keine Panstamps mehr und die verwendete SWAP Library funktioniert ausschließlich mit Panstamps (da habe ich schon ein paar Tage probiert die Lib auf Arduino zu portieren)
https://wiki.fhem.de/wiki/PanStamp_FensterkontaktSensor
https://github.com/tobiasfaust/WindowStatusSensor
Pro Fenster benötigt man 2 Reedkontakte, einen oben und einen unten. Damit kann man sauber erkennen ob das Fenster geschlossen, offen oder angeklappt ist.
An einem Arduino habe ich schon nach Abzug der SPI Pins 12 Reedkontakte angeschlossen bekommen (-> https://github.com/tobiasfaust/Panstamp_AVR_FullCounter12_PCINT)
Kann man irgendwo nachlesen wie die Lib funktioniert? Im Netz finde ich nur fertige sketche und Anleitungen wie man diese auf die Arduinos flasht. Leider keine "Einführung" in die Asksin Entwicklung. Die Asksin ist für mich absolutes Neuland da ich bisher ausschliesslich SWAP eingesetzt habe.
Wie kann man zb. den ThreeStateSensor von papa so erweitern das zb. bis zu 6 logische Devices (zb. Fenster) mit je 2 Reedkontakten verwendet werden können?
Ich habe gestern Abend mal schnell was zusammen gehackt und hier angehängen.
Der Sketch implementiert ein neues HM-Device HB-Sec-RHS-x4 (DeviceID 0xf20E) mit 4 ThreeStateChannels. Dafür werden jeweils 2 Reedkontake pro Channel benötigt. Die Pins sind von diesem Projekt hier geklaut
https://github.com/pa-pa/HMRemote
Sollten alle frei sein und funktionieren. Im Prinzip könntest Du sogar die Hardware dafür verwenden und einfach die Taster durch die Reedkontakte ersetzen. Könnte sein, dass ich auch noch Platinen irgendwo rumfliegen habe.
Damit FHEM das auch versteht, muss noch das AskSinPP-Addin mit der entsprechen Definition erweitert werden.
Falls das nicht auf Anhieb funktioniert - wovon ich mal ausgehe - können wir auch erst mal einen "einfachen" RHS im Sketch umsetzen. Den versteht FHEM auch ohne Addin. Und dann das ganze auf 4 Channel erweitern.
Hi papa,
besten dank dafür.... Ich habe mal versucht den Sketch zu verstehen. Eigentlich ist ja nur eine Config ;)
Hab trotzdem noch nicht ganz durchblicken können.
Ich bau es mir nächste Woche auf dem Breadboard nochmal neu auf und teste es. Ich melde mich dann zurück :)
Hi Papa,
nachdem sich 2 stück meiner 3.3v 8Mhz Arduinos 328p als eine 5V mit 16mhz entpuppt haben, hat das Flashen auf den dritten erfolgreich funktioniert.
11:29:29.888 -> AskSin++ v5.0.0 (Nov 22 2021 11:08:18)
11:29:29.888 -> Address Space: 32 - 298
11:29:29.888 -> CC init1
11:29:29.888 -> CC Version: 04
11:29:29.921 -> - ready
11:29:29.921 -> Activate Cycle Msg
11:33:57.261 -> ignore 0D 91 84 10 379576 F12005 06 01 0F 00 - 1271
11:36:12.887 -> ignore 0E 49 A4 10 307C2C F12005 06 01 C8 00 4B - 1908
11:36:14.884 -> ignore 0B 8E A0 01 F12005 3E9C25 01 0E - 1929
11:36:17.181 -> ignore 0A DB 80 02 F12005 3FC93E 00 - 1947
11:36:18.314 -> ignore 0B 50 B0 01 F12005 2F3686 01 0E - 1961
11:36:18.447 -> ignore 0E 50 A0 10 2F3686 F12005 06 01 01 00 3F - 1972
11:36:18.613 -> ignore 0F 77 86 10 36D80C 000000 0A 88 B8 08 00 40 - 1984
11:36:19.445 -> ignore 0E F8 A0 10 4ABCD8 F12005 06 01 01 00 30 - 1998
11:36:20.376 -> ignore 0B 3D B0 01 F12005 2F3545 01 0E - 2013
11:36:22.907 -> ignore 0B 9C B0 01 F12005 2F35CA 01 0E - 2033
11:36:24.970 -> ignore 0B DD B0 01 F12005 2F3661 01 0E - 2052
11:36:25.103 -> ignore 0E DD A0 10 2F3661 F12005 06 01 01 00 27 - 2062
11:36:25.969 -> ignore 0B F0 B0 01 F12005 2F3619 01 0E - 2076
11:36:26.248 -> ignore 0A F0 80 02 F12005 2F3619 00 - 2086
11:36:26.999 -> ignore 0B 3A B0 01 F12005 2F35B6 01 0E - 2099
11:36:27.265 -> ignore 0A 3A 80 02 F12005 2F35B6 00 - 2109
11:39:23.072 -> ignore 0F 68 86 10 38EF87 000000 0A 88 B8 09 00 40 - 2928
11:41:08.401 -> ignore 0F D8 94 3F F12005 000000 02 02 29 2E 30 44 - 3426
11:41:37.702 -> ignore 0E BE A4 10 536080 F12005 06 01 C8 00 4D - 3571
11:41:40.333 -> ignore 0E B8 A4 10 307C2C F12005 06 01 C8 00 4B - 3596
11:41:43.558 -> ignore 0E AB A4 10 3E9A52 F12005 06 01 C8 00 3A - 3620
11:41:46.314 -> ignore 0B C7 B0 01 F12005 2F3686 01 0E - 3643
11:41:47.846 -> ignore 0A C7 80 02 F12005 2F3686 00 - 3659
11:41:49.440 -> ignore 0E D2 A0 10 4AC280 F12005 06 01 01 00 3B - 3676
11:41:49.506 -> ignore 0B E1 B0 01 F12005 2F3545 01 0E - 3686
11:41:51.836 -> ignore 0B E1 B0 01 F12005 2F3545 01 0E - 3706
11:41:55.295 -> ignore 0B E1 B0 01 F12005 2F3545 01 0E - 3733
11:41:56.426 -> ignore 0B E1 B0 01 F12005 2F3545 01 0E - 3747
11:41:57.591 -> ignore 0B E1 B0 01 F12005 2F3545 01 0E - 3760
11:41:58.689 -> ignore 0B A1 B0 01 F12005 2F3661 01 0E - 3774
11:41:59.455 -> ignore 0B 8E B0 01 F12005 2F3619 01 0E - 3786
11:42:00.187 -> ignore 0B 22 B0 01 F12005 2F35CA 01 0E - 3801
11:42:00.987 -> ignore 0B 4A B0 01 F12005 2F35B6 01 0E - 3813
11:42:01.253 -> ignore 0A 4A 80 02 F12005 2F35B6 00 - 3823
11:42:01.752 -> ignore 0B 8E B0 01 F12005 2F3619 01 0E - 3833
11:42:02.485 -> ignore 0B A1 B0 01 F12005 2F3661 01 0E - 3846
In meinem FHEM Verzeichnis hatte cih noch eine alte "99_Asksin_HM_LC_Sw1PBU_FM_CustomFW.pm" die ich entfernt habe.
Deine "HMConfig_AskSinPPCustom.pm" habe ich ins FHEM Verzeichnis gelegt. Ebenso die HMMsg.pm (https://github.com/pa-pa/AskSinPP/blob/master/examples/custom/contrib/FHEM/HMMsg.pm) die noch gefehlt hat.
Weiterhin hat noch die initialisierung von "my $batflags = 0" gefehlt. Habe ich hinzugefügt und dann konnte die pm eingeladen werden :)
Habe dann den Config Taster kurz zum anlernen gedrückt, vorher in FHEM im VCCU Device ein "hmPairForSec 60" abgesetzt:
11:58:09.634 -> AskSin++ v5.0.0 (Nov 22 2021 11:08:18)
11:58:09.634 -> Address Space: 32 - 298
11:58:09.634 -> CC init1
11:58:09.634 -> CC Version: 04
11:58:09.634 -> - ready
11:58:09.634 -> Activate Cycle Msg
11:58:14.496 -> debounce
11:58:14.562 -> pressed
11:58:14.795 -> released
11:58:14.829 -> <- 1A 01 84 00 F20E00 000000 10 F2 0E 70 61 70 61 66 32 30 65 30 30 80 04 01 00 - 120
11:58:14.862 ->
11:59:40.874 -> -> 0D B5 A6 41 3795CF F12005 01 BA 70 80 - 20426
11:59:53.730 -> ignore 0F 6D 86 10 501EFA 000000 0A 24 C8 0C 00 40 - 20987
2021.11.22 11:57:43 3: CUL_HM set VCCU hmPairForSec 60
2021.11.22 11:58:14 2: CUL_HM Unknown device HM_F20E00 is now defined
2021.11.22 11:58:14 2: autocreate: define HM_F20E00 CUL_HM F20E00
2021.11.22 11:58:14 3: CUL_HM pair: HM_F20E00 no, model HB-Sec-RHS-x4 serialNr
2021.11.22 11:58:49 2: HMinfo hminfo get:configCheck :-f,^(HM_F20E00|HM_F20E00)$
2021.11.22 11:59:10 2: AttrTemplates: got 205 entries
2021.11.22 12:01:57 3: CUL_HM set HM_F20E00 getConfig noArg
Bei einem getConfig bekomme ich einen Timeout
Internals:
.triggerUsed 1
CFGFN
CUL_HM_MSGCNT 12
CUL_HM_RAWMSG A1003A001F10000F20E0000040000000000::-74.5:CUL_HM
CUL_HM_RSSI -74.5
CUL_HM_TIME 2021-11-22 12:10:35
DEF F20E00
FUUID 619b77c6-f33f-99a0-f9b3-9632320b83b2277d
HMWiFiBridge_MSGCNT 1
HMWiFiBridge_RAWMSG 0500004E018400F20E0000000010F20E7061706166323065303080040100
HMWiFiBridge_RSSI -78
HMWiFiBridge_TIME 2021-11-22 11:58:14
IODev HMWiFiBridge
LASTInputDev CUL_HM
MSGCNT 13
NAME HM_F20E00
NOTIFYDEV global
NR 459
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
chanNo 01
lastMsg No:01 - t:00 s:F20E00 d:000000 10F20E7061706166323065303080040100
protCmdDel 5
protErrIoId_F10000 12 last_at:2021-11-22 12:10:35
protLastRcv 2021-11-22 11:58:14
protRcv 2 last_at:2021-11-22 11:58:14
protResnd 6 last_at:2021-11-22 12:10:34
protResndFail 2 last_at:2021-11-22 12:10:39
protSnd 2 last_at:2021-11-22 12:10:18
protState CMDs_done_Errors:1
rssi_at_HMWiFiBridge cnt:2 min:-78 max:-78 avg:-78 lst:-78
.attraggr:
.attrminint:
Helper:
DBLOG:
D-firmware:
DbLog:
TIME 1637578694.85392
VALUE 1.0
D-serialNr:
DbLog:
TIME 1637578694.85392
VALUE papaf20e00
cfgState:
DbLog:
TIME 1637579418.41622
VALUE updating
commState:
DbLog:
TIME 1637579439.04256
VALUE CMDs_done_Errors:1
sabotageAttackId_ErrIoId_F10000:
DbLog:
TIME 1637579435.13017
VALUE cnt:12
state:
DbLog:
TIME 1637579439.04924
VALUE RESPONSE TIMEOUT:RegisterRead
READINGS:
2021-11-22 11:58:14 .D-devInfo 040100
2021-11-22 11:58:14 .D-stc 80
2021-11-22 11:58:14 .R-pairCentral set_0xF12005
2021-11-22 11:58:19 .associatedWith HM_F20E00,HM_F20E00
2021-11-22 11:58:14 .protLastRcv 20211122115814
2021-11-22 11:58:14 D-firmware 1.0
2021-11-22 11:58:14 D-serialNr papaf20e00
2021-11-22 12:10:18 cfgState updating
2021-11-22 12:10:39 commState CMDs_done_Errors:1
2021-11-22 12:10:35 sabotageAttackId_ErrIoId_F10000 cnt:12
2021-11-22 12:10:39 state RESPONSE TIMEOUT:RegisterRead
RegL_00.:
VAL
helper:
HM_CMDNR 3
PONtest 1
cSnd 01F12005F20E0000050000000000,01F10000F20E0000040000000000
mId no
supp_Pair_Rep 0
cfgChk:
idRc01 RegL_00.
cmds:
TmplKey :no:1637578699.84548
TmplTs 1637578699.84548
cmdKey 1:1:0::HM_F20E00:no:01:
cmdLst:
clear (readings|all)
getConfig noArg
getRegRaw (List0|List1|List2|List3|List4|List5|List6) [-peerChn-]
peerBulk -peer1,peer2,...- [({set}|unset)]
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2-...
regSet [(prep|{exec})] -regName- -value- [-peerChn-]
tplDel -tplDel-
tplSet_0 -tplChan-
update noArg
virtual [(1..50;1|{1})]
lst:
condition slider,0,1,255
peer
peerOpt
tplChan
tplDel
tplPeer
rtrvLst:
cmdList [({short}|long)]
deviceInfo [({short}|long)]
listDevice [({all}|alive|unknown|dead|notAlive)]
param -param-
reg -addr- -list- [-peerChn-]
regList noArg
regTable noArg
regVal -addr- -list- [-peerChn-]
saveConfig [-filename-]
status noArg
tplInfo noArg
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +F20E00,00,00,00
nextSend 1637578694.89208
prefIO
rxt 0
vccu VCCU
p:
F20E00
00
00
00
mRssi:
mNo 01
io:
CUL_HM:
HMWiFiBridge:
-76
-76
prt:
bErr 0
sProc 0
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rssi:
at_HMWiFiBridge:
avg -78
cnt 2
lst -78
max -78
min -78
shadowReg:
RegL_00. 02:01 0A:F1 0B:20 0C:05
tmpl:
Attributes:
.mId F20E
IODev VCCU
IOgrp VCCU
autoReadReg 4_reqStatus
expert rawReg
firmware 1.0
model HB-Sec-RHS-x4
room CUL_HM
serialNr papaf20e00
subType no
Wenn ich nun beim Ardino den Pin PC0 (also Reed01) gegen GND verbinde, wird ein Message versendet die auch im FHEM Hm Modul ankommt:
trigDst_broadcast -> Value: noConfig
trigger_cnt -> Value: 3 (-> hochzählend)
Grundsätzlich siehts wirklich sehr gut aus :)
Wo muss man jetzt ansetzen damit die 4 Gruppen in FHEM jetzt korrekt mit dem Status (open,closed,tilted) angezeigt werden?
Hat das etwas zu sagen wenn ich ein "RESPONSE TIMEOUT:RegisterRead" bekomme?
Klingt doch schon mal nicht schlecht. Der Timeout sollte nicht sein.
Beim Anlernen hat er irgendwie die Serial nicht mit dabei. Ich wiederhole das Anlernen dann immer. Beim zweiten mal klappt es dann meist.
2021.11.22 11:58:14 3: CUL_HM pair: HM_F20E00 no, model HB-Sec-RHS-x4 serialNr
Eigentlich sollte es neben dem Hauptgerät noch 4 Kanäle mit _Sens_Nummer am Ende geben. Probiere doch noch ein zweites mal anlernen.
Vielleicht ist auch Dein Funkmodul nicht besonders gut. Dann gibt es auch Probleme mit der Kommunikation. Das lässt sich aber recht einfach mit dem FreqiTest rausfinden: https://asksinpp.de/Grundlagen/FAQ/Fehlerhafte_CC1101.html#ermittlung-der-cc1101-frequenz
ZitatDeine "HMConfig_AskSinPPCustom.pm" habe ich ins FHEM Verzeichnis gelegt.
hast du anschliessend fhem restart gemacht?
dein device zeigt kein subType.
Ich habe FHEM nochmal neu gestartet und nochmal neu angelernt.
Jetzt werden auch die Subtypen angelegt. Auffällig ist, das alles Gesendete bei FHEM ankommt. Wenn FHEM allerdings etwas sendet wird anscheinend nichts empfangen. Ein "get config" bleibt unbeantwortet.
Ich habe das FreqTest script durchlaufen lassen:
09:38:13.888 -> AskSin++ v5.0.0 (Nov 23 2021 09:37:58)
09:38:13.888 -> CC init1
09:38:13.888 -> CC Version: 04
09:38:13.921 -> - ready
09:38:13.921 -> Active ping is NOT enabled, looking for any telegram
09:38:13.921 -> Start searching ...
09:38:13.921 -> Freq 0x21656A 868.300 MHz: 41DAE2. 1 / -66dBm
09:38:47.487 -> Search for upper bound
09:38:47.520 -> Freq 0x21657A 868.306 MHz: F12005. 1 / -59dBm
09:38:47.620 -> Freq 0x21658A 868.313 MHz: 41DAE2. 1 / -73dBm
09:38:50.783 -> Freq 0x21659A 868.319 MHz: F12005. 1 / -59dBm
09:38:50.916 -> Freq 0x2165AA 868.325 MHz: BA7B9F. 1 / -96dBm
09:38:52.980 -> Freq 0x2165BA 868.332 MHz: 41DAE2. 1 / -69dBm
09:38:55.977 -> Freq 0x2165CA 868.338 MHz: F12005. 1 / -58dBm
09:38:56.110 -> Freq 0x2165DA 868.344 MHz: 38EF87. 1 / -60dBm
09:38:56.410 -> Freq 0x2165EA 868.351 MHz: F12005. 1 / -56dBm
09:39:00.292 -> Freq 0x2165FA 868.357 MHz: 41DAE2. 1 / -69dBm
09:39:04.355 -> Freq 0x21660A 868.363 MHz: F12005. 1 / -58dBm
09:39:04.487 -> Freq 0x21661A 868.370 MHz: 41DAE2. 1 / -57dBm
09:39:08.250 -> Freq 0x21662A 868.376 MHz: F12005. 1 / -57dBm
09:39:08.383 -> Freq 0x21663A 868.382 MHz: F12005. 1 / -58dBm
09:39:15.309 -> Freq 0x21664A 868.389 MHz: F12005. 1 / -60dBm
09:39:15.975 -> Freq 0x21665A 868.395 MHz: 0
09:40:16.124 -> Search for lower bound
09:40:16.124 -> Freq 0x21655A 868.294 MHz: 51C839. 1 / -56dBm
09:40:53.282 -> Freq 0x21654A 868.287 MHz: 0
09:41:53.480 ->
09:41:53.480 -> Done: 0x21655A - 0x21664A
09:41:53.480 -> Calculated Freq: 0x2165D2 868.341 MHz
09:41:53.480 -> Store into config area: 65D2...stored!
09:41:53.579 -> Going to sleep...
09:42:01.694 -> F12005. 1 / -80dBm
09:42:01.694 ->
09:42:01.694 -> Done: 0x21655A - 0x21664A
09:42:01.694 -> Calculated Freq: 0x2165D2 868.341 MHz
09:42:01.694 -> Store into config area: 65D2...stored!
09:42:01.793 ->
09:42:01.793 -> Old Config Freq was: 0x2165D2 868.341 MHzGoing to sleep...
Jetzt läuft es! Ein GetConfig lief durch und ein wechsel bei den Reedkontakten kommt sauber in den Channels an (hab jetz nur channel1 1 gestetet)
Als subType wird mir custom angezeigt, sollte das nicht "ThreeStateSensor" sein?
Eine Änderung konnte ich selbst anpassen: wenn kein Kontakt geschlossen ist ist das Fenster offen, sind beide Kontakte geschossen dann ist das Fenster geschlossen:
const uint8_t posmap[4] = {Position::State::PosA,Position::State::PosC,Position::State::PosC,Position::State::PosB};
Könnte man noch 1 Sache anpassen?
Ich habe es nicht geschafft das Gerät als Batteriebetrieben zu deklarieren sodass auf einem Pin die Spannung gemessen wird und ensprechend in FHEM eine Batteriewarnung beim Erreichen des Schwellwertes ausgegeben wird.
Gibt es eigentlich nachteile bei Batteriebetriebenen Geräten gegenüber permanent versorgten Geräten?
Ich kenne nur, das Konfigänderungen/Anforderungen nicht sofort erkannt werden sondern alle ca 5min.
Hintergrund: an einigen Fenstern habe ich keine 5V Versorgungsspannung. Dafür wollte ich mir Platinen bauen die eine CR123 drauf haben. Entsprechende Schaltungen mit einer AA Batterie und einem StepUp Wandler hatte ich schonmal in meinem Panstamp Bodenfeuchtesensor umgesetzt.
Na bitte - geht doch.
Der subType ist hier immer "custom". Das kann mal leider nicht ändern. Sonst klappt die Logic mit dem Addin nicht mehr. Zumindest soweit ich den FHEM-Perl-Code verstehe.
Die Batterie hatte ich extra ausgebaut :-( Ist aber kein Problem die wieder reinzunehmen.
Dann auch mit Register, um die LowBat-Schwelle einzustellen ?
Soll der Batteriewert auch bei jeder Nachricht mitgesendet werden - so wie es der RHS-3 macht ?
Zitat von: papa am 23 November 2021, 13:51:28
Dann auch mit Register, um die LowBat-Schwelle einzustellen ?
Soll der Batteriewert auch bei jeder Nachricht mitgesendet werden - so wie es der RHS-3 macht ?
ich würde sagen, beides ja...
andere Frage, kann eigentlich der Arduino per ISP geflashed werden während der CC1101 dran hängt oder stört dieser?
Hintergrund: wenn alles auf der Platine drauf gelötet ist muss ja auch mal die FW aktualisiert werden (ohne ota)
Hi papa,
ich habe im ersten Wurf mit Standardkomponenten eine Version mit externer 5V Stromversorgung für meine Unterputzsensoren zusammen gedengelt.
Eine Batterieversion mit Spannungsmessung und CR123 kommt später wenn diese Version hier funktioniert da mit einer Batterie ein Standard Arduino MiniPro nicht mehr drauf passt und ich den ATMEGA mit dem Quarz selbst layouten muss.
Kannst du mal auf den Schaltplan schauen ob aus deiner Sicht es so passt?
Zitat von: Tobias am 24 November 2021, 14:00:54
Hi papa,
ich habe im ersten Wurf mit Standardkomponenten eine Version mit externer 5V Stromversorgung für meine Unterputzsensoren zusammen gedengelt.
Eine Batterieversion mit Spannungsmessung und CR123 kommt später wenn diese Version hier funktioniert da mit einer Batterie ein Standard Arduino MiniPro nicht mehr drauf passt und ich den ATMEGA mit dem Quarz selbst layouten muss.
Kannst du mal auf den Schaltplan schauen ob aus deiner Sicht es so passt?
Sieht soweit gut aus. Hab nur schnell mit dem Standard-Schaltplan verglichen
https://asksinpp.de/Grundlagen/01_hardware.html#verdrahtung
Schau mal hier https://github.com/Asselhead/Arduino-Pro-Mini-RF
Das ist eine Pro-Mini Pin-kompatible Platine mit CC1101 schon drauf. Vielleicht reicht der Platz dann noch für die Batterie.
Ah, danke. diese Seite kannte ich noch nicht. Merke ich mir.
Das ist sozusagen eine 1:1 Version des "Panstamps AVR 1". Das war auch eine fertige Platina mit Atmega328p und einem Cc1101.
Leider ist bei jlcpcb der ATMEGA328P-MU ausverkauft, sonst hätt ich mich fast hinreissen lassen ein paar testplatinen zu ordern....
Habe jetzt aber mal eine Handvoll nachte Platinen von meinem Entwurf (s.o.) bestellt. Diese passten exakt in eine 60mm Unterputzdose. Ich melde mich sobald diese da sind und ich testen kann :)
Was machen die Fenster ?
Hi
Die Platinen kamen kurz vor Weihnachten an.
Habe gerade heute die erste zusammen gelötet. Muss jetzt noch den Sketch mit den korrekten Pins anpassen und dann hoffe ich das alles klappt.
Habe heute schon nerven gelassen meinen mySmartUSB light mit der Arduino IDE ans laufen zu bekommen.
Melde mich
Hi Papa,
scheint erstmal alles zu funktionieren.
Ich habe hier ziemlich lange an einem HardwareDebounce Problem zu kämpfen gehabt.
Habe wie immer einen 2.2uF zwischen den ReedEingangsPins (zb. A0) und GND auf meiner Platine gesetzt. Ergebnis ist, das die Eingänge ständig auf GND gezogen waren und eine Statusänderung quasi nicht erkannt wird. Nehme ich den Cap raus, funktioniert alles.
Ich bin ratlos warum der Debouncer nicht funktioniert. Irgendeine Idee?
Edit: hier die Fotos der fertig aufgebauten Platine mit wieder ausgelöteten caps :(
Könnte vielleicht das selbe Problem wie hier sein
https://forum.fhem.de/index.php/topic,57486.msg1196038.html#msg1196038
ich bin mir nicht sicher ob es dasselbe problem ist. Das wirft für mien VErständnis aber eine neue Frage auf. Wenn der Pin immer wieder auf LOW gezogen wird, wie wird dann eine Statusänderung erkannt? Wird in der Lib nicht intern mit der PinChangeInterrupt Lib gearbeitet? Dazu muss doch der Pin aber permanent auf INPUT_PULLUP gezogen sein?
Duch das Signal LOW wird der aufgeladene CAP quasi kurzgeschlossen. Dadurch ist er leer und verbindet LOW-Signal mit GND. Das könnte das Problem sein. ICh hatte es nur gut gemeint und extra den 2.2uF als Debouncer eingebaut. Muss ich jetzt eben weglassen.
GRundsätzlich funktioniert alles.
@papa, kannst du Sketch und HM-Modul Erweiterung bei dir im Repo und im FHEM-Repo einchecken?
Zitat von: Tobias am 05 Januar 2022, 13:37:04
ich bin mir nicht sicher ob es dasselbe problem ist. Das wirft für mien VErständnis aber eine neue Frage auf. Wenn der Pin immer wieder auf LOW gezogen wird, wie wird dann eine Statusänderung erkannt? Wird in der Lib nicht intern mit der PinChangeInterrupt Lib gearbeitet? Dazu muss doch der Pin aber permanent auf INPUT_PULLUP gezogen sein?
Nein - es wird kien Interrupt verwendet, sondern im Sekundentakt gepollt. Dazu wird der Pin auf Eingang gestllt, der Status gelesen und dann wieder auf Output LOW gestellt. Dadurch wird bei dauerhaft auf GND gezogenen Pin kein Stromverbrauch. Aber wie wir jetzt sehen, hat das auch "nette" Nebeneffekte.
Zitat von: Tobias am 05 Januar 2022, 13:37:04
Duch das Signal LOW wird der aufgeladene CAP quasi kurzgeschlossen. Dadurch ist er leer und verbindet LOW-Signal mit GND. Das könnte das Problem sein. ICh hatte es nur gut gemeint und extra den 2.2uF als Debouncer eingebaut. Muss ich jetzt eben weglassen.
Das hatte ich auch gleich gedacht, als ich Deine Nachricht gelesen habe. Durch das Pollen gibt es keine Bouncing-Probleme.
Zitat von: Tobias am 05 Januar 2022, 13:37:04
GRundsätzlich funktioniert alles.
@papa, kannst du Sketch und HM-Modul Erweiterung bei dir im Repo und im FHEM-Repo einchecken?
Beim mir kann ich das gerne einchecken. Für FHEM nicht.
Zitat von: papa am 05 Januar 2022, 15:04:49
Dadurch wird bei dauerhaft auf GND gezogenen Pin kein Stromverbrauch. Aber wie wir jetzt sehen, hat das auch "nette" Nebeneffekte.
... dass, wenn der Pin wieder als Eingang geschaltet wird, der 2.2 uF Kondensator über den Internen Pullup ne entsprechende Zeit zum Laden benötigt, um am Eingang wieder einen Pegel zur Verfügung zu stellen, der als HIGH erkannt wird.
LG
Papa Romeo
wer kann denn die HM-Modul Erweiterung im FHEM Repo einchecken?
Schau mal - das könnte für die Batterievariante interessant sein:
https://github.com/jp112sdl/HB-SCI-x-MSP
Sorry, wenn ich hier dazwischenkomme. Ich habe nämlich zufällig gesehen, dass hier mein Problem 'gestreift' wird.
In meinem Scetch möchte ich den Status von zwei PINs abfragen, die als PINs in einem TwoStateChannel konfiguriert sind. Ich lese aber immer LOW, selbst wenn der Eingang HIGH sein sollte.
papa hat ja oben die Erklärung dazu geliefert "wird nur im Sekundentakt mal kurz als INPUT geschaltet" und ist sonst OUTPUT, LOW.
Details habe ich im Thread Homematik angegeben https://forum.fhem.de/index.php/topic,126125.msg1207277.html#msg1207277 (https://forum.fhem.de/index.php/topic,126125.msg1207277.html#msg1207277) .
Die PINS sind Endschalter für eine Markise und der Motor darf nicht darüber hinausfahren. Die Steuerung eine um ein TwoStateChannel erweiterte Rolladensteuerung HM-LC-Bl1-FM.
papa kann folgende Frage vermutlich sofort beantworten:
Kann ich den Status der PINs im Scetch in dem TwoStateChannel abfragen? - digitalRead() liefert ja LOW, während der PIN ein OUTPUT ist.
Danke,
Gregor
nach etwas mehr Suche... das Problem existiert ja offenbar nicht mehr.
In der aktuellen AskSinPP lib bleibt ein Eingang dauerhaft INPUT (während der Messung INPUT_PULLUP).
Damit sollte mein Problem gelöst sein, werde ich morgen gleich testen.
OK, Problem gelöst.
Mit der aktuellen AskSinPP Library liefert digitalRead() jederzeit den realen Status vom Sensor. Und das Problem, was Tobias geschildert hat, hatte ich auch. Bei mir waren es 100nF Kondensatoren, die dazu führten, dass der HIGH Status (trotz eines externen 10K PullUp) nicht mehr gelesen werden konnten. Wenn der PIN auf LOW gezogen wird und nur für die Messung kurzzeitig gelesen wird, reicht die Messzeit nicht aus um einen Entstörkondensator so hoch zu laden, dass ein HIGH gelesen werden kann.
Die jetzige Variante, den PIN auf INPUT zu setzen ist auch aus diesem Grund erheblich sicherer - gar nicht zu reden von Signalen, die aktiv auf HIGH gezogen werden und damit dann einen Kurzschluss (zumindest hohen Strom) erzeugt hatten.
Hi papa,
ich habe jetzt den Fall, das ich in einer Tür einen normalen Reedkontakt oben angebracht habe. Damit weiss ich ob die Tür auf oder zu ist. Weiterhin habe ich im Türschloss einen Schließkontaktsensor. Damit weiß ich ob die Tür abgeschlossen ist oder nicht.
Nun wollte ich im Sensor, im Channel folgendes machen:
set <dev> regset msgRhsPosA locked
aber leider gibt es nur vordefinierte formate:
invalid value. use:closed,noMsg,open,tilted
Irgendeine Idee wie ich die states [open|closed|locked] hinbekomme?
Nur mit einen eigenen Gerät.
Siehe https://github.com/pa-pa/AskSinPP/blob/5bc817e1a5341c27434d26d476ed30f69e29fe46/examples/custom/contrib/FHEM/HMConfig_AskSinPPCustom.pm#L337
Hi papa,
ich denk mir etwas fhem-internes aus. Ich denke an ein Userreading für einen eigenes state. Oder an "stateFormat". An einem Device hängen manchmal fenster und türen zusammen ;)
Ich habe heute meinen zweiten Sensor zusammengebaut, diesmal fest verlötet ohne Steckschuhe damit der Aufbau niedriger wird.
Funktioniert super :)
Ich habe mal alles hier dokumentiert: https://github.com/tobiasfaust/WindowStatusSensor/tree/master/ATMega328p%20Version
Der sensor wird an 5V angeschlossen und Arduino Mini als auch CC1101 werden durch den externen 3,3V LDO versorgt.