Forum

Bitte oder Registrieren, um Beiträge und Themen zu erstellen.

Binding für OpenHab2?

Hallo!

Vielen Dank für das Erstellen des GitHub Projektes!

Derzeit nutze ich noch die V0.5 von Steffen. Derzeit überwiegen für mich noch die Nachteile, die vorhanden sind.
Ich habe auch noch nie etwas mit MQTT gemacht. Da muss ich mich erst einlesen und schauen, wie ich das in FHEM einbinden kann.
Für mich ist der Empfang ebenfalls sehr wichtig. Ich habe eine einfache Beschattungssteuerung (DOIF in Verbindung mit dem ROLLO Modul) möchte aber auch darauf reagieren, wenn manuell über eine Fernbedienung die Position verändert wurde. Wäre also super, wenn das noch irgendwann kommt.
Was die Gruppen angeht...eigentlich müssen ja nicht alle Rolladen gleichzeitig losfahren. Nacheinander starten geht ja auch. Und die Umsetzung ist in FHEM schnell gemacht. Beim Empfang wird es interessanter. Über die Fernbedienung schalten wir meist die Gruppe. Da will man nicht einzeln durchtickern.

Ich habe bei meinem Selbstbau FHEM CUL (SIGNALduino ebenfalls 433MHz...wäre auch interessant das damit alles zu machen) mehrere Möglichkeiten die Parameter (Frequenz,Bandwith etc.) anzupassen. Ich habe länger gebraucht, aber konnte durch "Feintuning" meine 433MHz Geräte doch wesentlich besser empfangen. Vielleicht könnte man die Parameter ebenfalls einstellbar machen (Stefen hat in seinem Code auch ein Menü drin...) um bessere Einstellungen zu finden?

Ich habe noch nicht so viele Erfahrungen in der Programmierung des ESP. Daher kann ich leider nicht sehr viel beisteuern. Ein neuer ESP und Sender ist aber bereits bestellt (dauert bestimmt noch bis das kommt) damit ich parallel testen kann.

Zum WLAN: Ich hatte mal ein anderes Projekt...dort wurde wenn das hinterlegte WLAN nicht gefunden wird auch in den Konfig-Modus gewechselt. Fand ich ebenfalls praktisch. Einmal in Keller wo kein WLAN ist...neu konfiguriert und wieder zurück.

Tolle Arbeit! Vielen Dank!

Gruß

Bismosa

Hi,

Was die Gruppen angeht...eigentlich müssen ja nicht alle Rolladen gleichzeitig losfahren. Nacheinander starten geht ja auch. Und die Umsetzung ist in FHEM schnell gemacht. Beim Empfang wird es interessanter. Über die Fernbedienung schalten wir meist die Gruppe. Da will man nicht einzeln durchtickern.

Hier sehe ich ein logisches Problem was es zu lösen gilt. Rolladen einzeln steuern und Rückmeldungen verarbeiten - okay, kein Thema. Wenn jetzt aber der Dongle ein Gruppenkommando von der Fernbedienung empfängt - was macht er damit? Wer zerlegt das Gruppenkommando in einzelne Meldungen und ordnet das den Rolladen zu?

Ich habe bei meinem Selbstbau FHEM CUL (SIGNALduino ebenfalls 433MHz...wäre auch interessant das damit alles zu machen) mehrere Möglichkeiten die Parameter (Frequenz,Bandwith etc.) anzupassen. Ich habe länger gebraucht, aber konnte durch "Feintuning" meine 433MHz Geräte doch wesentlich besser empfangen. Vielleicht könnte man die Parameter ebenfalls einstellbar machen (Stefen hat in seinem Code auch ein Menü drin...) um bessere Einstellungen zu finden?

Du bist wie jeder andere herzlichst eingeladen seine Verbesserungen einzubringen. Ich hab mal nachgeschaut - der SINGNALduino arbeitet auch mit dem CC1101 Funkchip - also sind Deine Erkenntnisse hier sehr wertvoll.

Das Menü auf der seriellen Schnittstelle in Steffens FHEM Version hab ich natürlich bemerkt, und auch nicht vollständig verstanden, aber "taucher4000" hat es entweder ausgebaut oder seine MQTT Version ist mit einer FHEM-Version gestartet wo das serielle Menü noch nicht drin war.

Steffen - sag mal was dazu - brauchen wir das Menü wieder? Ich kann den Code übernehmen, sollte nicht allzuviel Aufwand sein.

Ich habe noch nicht so viele Erfahrungen in der Programmierung des ESP. Daher kann ich leider nicht sehr viel beisteuern.

Na ja... bitte nicht so bescheiden... wenn Du Erfahrungen hast den CC1101 besser einzustellen und Reichweite und Empfindlichkeit zu optimieren - dann wirst Du SEHR VIEL beitragen. Und genau diese unterschiedlichen Erfahrungen sind es, die solche freien Projekte unheimlich gut voranbringen können.

Zum WLAN: Ich hatte mal ein anderes Projekt...dort wurde wenn das hinterlegte WLAN nicht gefunden wird auch in den Konfig-Modus gewechselt. Fand ich ebenfalls praktisch. Einmal in Keller wo kein WLAN ist...neu konfiguriert und wieder zurück.

Tja - das was Du da praktisch findest sehe ich ganz anders - und zwar durch die "Security-Brille". Ein Gerät in den Konfig-Modus zu bringen, ohne es physikalisch zu berühren, das geht gar nicht.

Stell Dir vor dein Nachbar findet das hier https://github.com/spacehuhn/esp8266_deauther um das WLAN zu stören - oder benutzt einen 2,4GHz Störsender - oder hat eine defekte Mikrowelle - oder eines von diesen schrecklichen analogen Video-Signal-Überträgern im 2,4GHz Band - dann poppen so designte IoT Geräte hinterher mit ihren Konfig-WLANs auf und alle Nachbarn können lustige Einstellungen Deinem Eigentum machen... also das ist definitiv nur anscheinend praktisch.

Ich hab die Methode "doppelter Reset innerhalb 10 sek." für den Konfig-Mode eingebaut - das war schnell gemacht, funktioniert absolut zuverlässig und ist sicher, da man das Gerät anfassen können muß um es umzukonfigurieren.

Und wenn mir jemand nachvollziehbar erklärt er braucht einen anderen Mechanismus - dann bauen wir den eben zusätzlich ein und machen es EINSTELLBAR wie es denn nun läuft. Und dann ist es eben wichtig, daß man Dinge einstellen kann, damit jeder glücklich wird.

Na dann, freue mich auf Erfahrungen zum CC1101

Ciao,

Martin

Das Menü habe ich damals einfach zum schnellen Testen der wichtigsten Parameter eingebaut. Wenn wir einmal die optimalen Einstellungen gefunden habe, sollte es für alles passen. Im TI-Forum unter: https://e2e.ti.com/support/wireless_connectivity/proprietary_sub_1_ghz_simpliciti/f/156/t/148027sind Einstellungen für Keeloq gepostet worden. Ich meine jedoch, dass diese nicht optimal waren.

Hauptsächlich habe ich mit der Frequenz, der Bandbreite und den Parametern

CC1101_DEFVAL_AGCCTRL2

CC1101_DEFVAL_AGCCTRL1

CC1101_DEFVAL_AGCCTRL0

rumgespielt.

Ich versuche nebenbei die Empfangsroutine zu ändern/verbessern. Auch wäre es vlt. möglich eine CRC zu generieren. Lt. Datenblättern von Microchip ist das in Keeloq implementiert.

Hallo,

Hier sehe ich ein logisches Problem was es zu lösen gilt. Rolladen einzeln steuern und Rückmeldungen verarbeiten - okay, kein Thema. Wenn jetzt aber der Dongle ein Gruppenkommando von der Fernbedienung empfängt - was macht er damit? Wer zerlegt das Gruppenkommando in einzelne Meldungen und ordnet das den Rolladen zu?

Tja. Da hört mein Halbwissen auch schon wieder auf. Ich hatte das so verstanden, das in den Disc-Werten diese Informationen enthalten sind. Aber so richtig durchgestiegen bin ich da noch nicht.

der SINGNALduino arbeitet auch mit dem CC1101 Funkchip - also sind Deine Erkenntnisse hier sehr wertvoll

Naja. Letztendlich habe ich mit Hilfe eines DVB-T Sticks die Frequenzen beobachtet und den Stick dann auf diese Frequenz getrimmt. Hier ein auszug aus der Doku:

  • freq / bWidth / patable / rAmpl / sens
    Only with CC1101 receiver.
    Set the sduino frequency / bandwidth / PA table / receiver-amplitude / sensitivity
    Use it with care, it may destroy your hardware and it even may be illegal to do so. Note: The parameters used for RFR transmission are not affected.

    • freq sets both the reception and transmission frequency. Note: Although the CC1101 can be set to frequencies between 315 and 915 MHz, the antenna interface and the antenna of the CUL is tuned for exactly one frequency. Default is 868.3 MHz (or 433 MHz)
    • bWidth can be set to values between 58 kHz and 812 kHz. Large values are susceptible to interference, but make possible to receive inaccurately calibrated transmitters. It affects tranmission too. Default is 325 kHz.
    • patable change the PA table (power amplification for RF sending)
    • rAmpl is receiver amplification, with values between 24 and 42 dB. Bigger values allow reception of weak signals. Default is 42.
    • sens is the decision boundary between the on and off values, and it is 4, 8, 12 or 16 dB. Smaller values allow reception of less clear signals. Default is 4 dB.

Also ich habe bisher nur die Standard-Frequenz von 433,92 MHz auf 433,8 MHz gesetzt und die Bandbreite auf 500kHz. Damit konnte ich dann meine Geräte alle empfangen.  Aber eigentlich handelt es sich hier um die benötigten Sachen um den Empfang zu verbessern.

Eigentlich würde es mir gut gefallen, wenn man Senden/Empfangen über den CUL direkt machen könnte. Aber soweit ich weiß ist die Keeloq-Implementierung in den CUL unerwünscht. Ich werde nochmal mit den empfangenen RAW Werten spielen...vielleicht kommt da ja auch was brauchbares bei raus.

Gerät in den Konfig-Modus zu bringen, ohne es physikalisch zu berühren, das geht gar nicht.

Stimme ich dir voll und ganz zu! Also bloß keine Gedanken drum machen...es gibt wichtigeres 🙂

Gruß

Blondie

Zum Thema Empfangen der Befehle von Fernbedienungen würde ich gern noch folgendes zu bedenken geben:

 

1.  Gesetzt dem falle, dass das auswerten der Fernbedienung im sketch implementiert ist: Der Rolladen selber hat keinerlei Sendefunktion. Er empfängt einfach nur die Befehle (insofern verstanden) und führt diese dann aus. Wenn also z.B. ein Befehl der Fernbedienung gesendet wurde, dieser Befehl dann auch vom Dongle empfangen wurde und entsprechend der Status gesetzt wurde ABER der Rolladen den Befehl NICHT empfangen hat, so stimmt der Status im Dongle mit der tatsächlichen Position nicht überein. Anders herum genau so. Der Rolladen hat den Befehl verstanden aber er Dongle nicht.

 

2. Wenn jemand zusätzlich zu den Funkfernbedienungen noch einen Taster an den Rolladen verbaut hat, mit dem man diesen ja auch hoch- und runterfahren kann, so bekommt das der Dongle auch nicht mit. Somit stimmt die Position im Dongle mit der tatsächlichen Position auch nicht überein.

 

Soll heißen: Die tatsächliche Position des Rolladens ist in keinem falle 100% garantiert. Es ist mehr oder weniger nur eine Annahme. Demzufolge stellt sich für mich die Frage, ob sich der Aufwand wirklich lohnt, eine Funktion zur Auswertung von Fernbedienungsbefehlen zu implementieren, die entsprechenden Seriennummern im Frontend/Dingle zu pflegen und dann doch nur eine sehr ungenaue Aussage der Position zu bekommen. Zudem besagt die Position ja nur, dass der Rolladen hoch- oder Runtergefahren ist. Wenn ich den Rolladen ein Stück runter fahre und dann stoppe (z.b. 25% geschlossen), so ist diese Position  sowieso NIE auswertbar.

 

Meiner Meinung nach ist also diese Art der Auswertung der Fernbedienungsbefehle Hardware-Bedingt durch die Jarolift-Komponenten nicht wirklich sinnvoll. Andere System, welche eine Zwei-Wege-Kommunikation haben (z.B. Velux Rolläden) können dies viel besser.

 

Das ist aber nur meine Meinung dazu. Bin gespannt, was Ihr dazu sagt 🙂

Also prinzipiell hast du natürlich Recht, aber...

zu 1) die Rollläden empfangen -zunmindest bei mir- eigentlich immer das Signal der Fernbedienung

zu 2) Ich habe z.B. keine Taster

Daher würde mal schätzen, dass in über 90% der Fälle der Status stimmen würde.

Ich hätte nicht den Anspruch auf 100%. Die Garantie hat man ja auch nicht, wenn des Senden durch den ESP nicht vom Rollladen emfangen wurde.

Da bei uns die Fernbedienung noch oft genutzt wird, fände ich die Auswertung der Befehle nicht schlecht.

 

Mein Senf dazu 🙂

Also ich habe auch Taster und Fernbedienungen, die werden jedoch selten genutzt. Allerdings ist mir die Anzeige des tatsächlichen Zustands auch ziemlich egal. Wenn der Rollo runter ist und dann nochmal der Befehl per mqtt kommt, egal.

Ob da nun irgendwo ein Bildchen anzeigt in welchem Zustand der Rollo ist interessiert mich nicht allzu sehr. Spätestens bei Betreten des Raumes merke ich, ob rauf oder runter ist.

Idee dazu: Man könnte sich mit einem ESP und ESPeasy (oder Tasmota) ein Tastenfeld bauen wodrüber die Stati der Rollos basierend auf den MQTT-Nachrichten angezeigt werden und diese auch darüber steuern.

 

Es müsste ja nur die entsprechende Nachricht über MQTT gesendet werden, wer sie wie verarbeitet ist ja egal.

Man könnte ja auch über ein Flag steuern (falls es noch nicht der Fall ist), ob eine Nachricht bei eingehenden 'Fremdsignalen' gesendet werden soll.

P.s. ich mach  selber genug Rechtschreib- und Grammatikfehler und will ja auch nicht klugscheißen, also nimm's mir nicht übel ... aber die Mehrzahl von Status ist Status (ausgesprochen mit langem 'u') - nicht Stati ! 😉

Auch wir benutzen fast nur die Fernbedienung(en).

Allerdings nutze ich die Funktaster TDRCT 04W. Also ist eine Bedienung auch direkt am Fenster möglich.

Ich nutze in FHEM das Modul "ROLLO". Das schätzt aufgrund der Fahrzeiten relativ genau die Position des Rolladen. So kann ich z.B. mittags zum beschatten auf 50% fahren und es kommt meistens (wenn nicht manuell gefahren wurde) recht gut hin.

Ich würde die Funktion toll finden!

P.S: Ich versuche mich derzeit an die Auswertung der RAW-Daten aus dem CUL (SIGNALduino). Aber es macht den Anschein, das auch hier nur sporadisch passende Werte ankommen. Wenn ich weitere Erkentnisse habe, werde ich die hier mitteilen!

Na brat mir nen Storch 🙂 Tatsächlich, es gibt sogar eine Webseite dazu: http://status-mehrzahl.de/

Also, beschatten ist einfacher über die Shade-Stellung möglich(finde ich). Ich würde dann einfach alles was nicht ganz zu oder ganz auf als shade interpretieren lassen.

Wenn man den im github angegebenen Wemos mit 4M nimmt werden gerade mal 31% Speicher gebraucht. Da ist also noch eine Menge Platz für zusätzliche Funktionen. Timer und so würden mir da als erstes einfallen dann könnte das ganze noch wesentlich autarker laufen. Und eigentlich gehört auch immer ein DS18x20-Temperatursensor dazu, wieso auch immer 🙂