Alternative culfw

Begonnen von bjoernh, 15 März 2015, 12:01:06

Vorheriges Thema - Nächstes Thema

Maista

Hallo Markus,

schade :-\ Dann brauch ich auch nicht weiter danach suchen.

Zumindest die Sensoren sehen nach Oregon aus.
Ich hab auch von irgendwoher ein Sensor der wird von nix erkannt.
THR122 steht da hinten drauf. Der ist von Oregon und sieht schon so aus wie das von Aldi.
Die Aldi-Teile muss es 2013 gegeben haben.
EAN 23247185. Da findet man viel nur keine Anleitung mehr ;(
https://www.aldi-sued.de/de/infos/aldi-sued-a-bis-z/s/serviceportal/ergebnisliste/sis/si/wetterstation-mit-4-tages-prog-1/

Gruß Gerd

Snocksman

Hallo zusammen,

ich habe seit kurzem ein Problem mit meinem nanoCUL... Erstmal zur installierten Firmware: V 1.26.04 a-culfw Build: 306 (2018-10-02_16-37-10) nanoCUL433 (F-Band: 433MHz) Und nun zum Problem: Ich empfange seit Jahren mit dem nanoCUL Temperatur- und Luftfeuchtedaten von einem Außenthermometer, aber seit neustem scheint das ganze leider nicht mehr zu funktionieren. Starte ich den Raspi neu, scheint der nanoCUL kurz (ca. 30 sec.) ein paar Daten zu empfangen, danach allerdings nicht mehr. Das Device des nanoCUL zeigt dann in den Readings: raw No answer Sende ich mit dem nanoCUL Kommandos an z.B. eine Intertechno Steckdose funktioniert dies, aber mit einer drei Sekunden Verzögerung; wärend ein Befehl gesendet wird, scheinen auch kurz wieder Daten vom Thermometer empfangen zu werden.
Ich habe die Vermutung, dass es damit zusammenhängt, dass ich den zweiten CUL, den ich für HM am Raspi hatte,(868Mhz von Busware) vor kurzem durch ein HmUART Modul ersetzt habe und folgende Änderungen durchgeführt habe:

config Änderung in FHEM:
attr initialUsbCheck disable 1

config Änderung in Raspbian:
# seriell-getty Dienst für ttyAMA0 dauerhaft deaktivieren
systemctl stop serial-getty@ttyAMA0.service
systemctl disable serial-getty@ttyAMA0.service
systemctl mask serial-getty@ttyAMA0.service

in der /boot/config.txt folgende Zeilen am Ende hinzugefügt:
enable_uart=1
dtoverlay=miniuart-bt
core_freq=250

in der /boot/cmdline.txt folgenden Eintrag gelöscht:
console=ttyAMA0,115200

Weitere Infos, Logs usw. liefere ich natürlich gerne, wenn benötigt. Es wäre super, wenn wir den Empfang von meinem Außenthermometer wieder ans laufen bekommen würden !!!

Snocksman

Habe gerade selbst herausgefunden, woran es gelegen hat... Ich habe mal versucht, eine neue Version der a-culfw auf den nanoCUL zu flashen. Der Vorgang brach immer nach einigen Prozent ab. Zuerst dachte ich der Arduino wäre evtl. defekt, also einen anderen drangestöpselt und nochmal probiert. Gleiches Problem. Beide Arduinos versucht an meinem Laptop zu flashen, kein Problem, funktionieren beide. Lösung: Scheinbar frisst das HmUART mehr Strom, als der Busware CUL, den ich zuvor für die Homematic Komponenten benutzt habe, so dass jetzt der nanoCUL zu wenig Strom bekommt. USB-HUB mit Stromversorgung zwischengestöpselt und alles läuft wieder wie gewohnt.  ::)

connaisseur

Hallo!

Habe einen zwei-fach Maple-CUL (868 MHz & 433 MHz) mir aus der Bucht geschossen.

Insb. der 433 MHz-Teil war interessant, da ich einen Stapel Oregon Scientific Sensoren habe, die auf meiner produktiven FHEM-Umgebung mit einem RFXtrx433 empfange. Die USB-Gerätschaften wollte ich eigenlich mal in Rente schicken.

Die THGR810-Sensoren funktionieren recht passabel. Meine Frage jetzt hier: Geht ein BTHR918-Sensor mit dem Maple-CUL 433 MHz auch?

Bekomme reichlich "Unknown code"-Meldungen. Daher die Frage.

Version String des CUL: V 1.26.08 a-culfw Build: 323 (2019-08-03_09-32-54) MapleCUNx4_83 (F-Band: 433MHz)

noansi

Hallo Björn,

Schau bitte mal hier rein https://forum.fhem.de/index.php/topic,129341.msg1236367.html#msg1236367.
Mir ist für SOMFY ein Bug für das Senden aufgefallen, der auch in der a-culfw steckt.

Gruß, Ansgar.