Neueste Beiträge

Seiten: [1] 2 3 ... 10
1
MQTT / Antw:MQTT_GENERIC_BRIDGE - Optimierungen für MQTT2-IO-Module
« Letzter Beitrag von hexenmeister am Heute um 00:31:00 »
Diese (gesamte) Fassung läuft jedenfalls bei mir hier im Hauptsystem seit ein paar Minuten, bringt aber dann noch zusätzlich diverse perlcritic-Änderungen und den 1. cref-Vorschlag (noch ohne Hinweis auf das mit dem 2-er-IO-Attribut).

Die wesentlichen Ideen:
- IO-TYPE-Bestimmung etwas optimiert;
- Die Zählung ist jetzt abhängig vom IO-TYPE. Sollte für die neuen IO's die Event-Flut eindämmen und für 00_MQTT.pm 100% kompatibel sein;
- Die Schleife zum Durchlaufen aller MGB-Instanzen ist umgebaut, es sollte jetzt immer NEXT zurückkommen. Da bin ich aber nicht sicher, ob das noch kompatibel zu 00_MQTT.pm ist, weil da das GP_Catch verwendet wird und ggf. jede MGB-Instanz separat aufgerufen wurde (?). Unklar ist mir aber warum dann für 00_MQTT.pm überhaupt das Array verwendet wurde, da hätte eigentlich dann nur die eine Instanz "durchlaufen" werden dürfen und dann macht es ggf. auch Sinn, das return "" zwischendurch zu lassen, aber eben dann mit der Prüfung, ob es 00_MQTT.pm war, das die ParseFn aufgerufen hat.
Den NEXT-Teil habe ich bisher nicht getestet...

- Ob die Optimierung für die IO-TYPE-Bestimmung so wirklich viel bringt - bin ich nicht überzeugt. Sind ja auch nur Zugriffe auf ("etwas weiter liegende") Hashes.
Bin da aber kein Profi. Wenn das wirklich was bringt - übernehme ich die Änderung. In jedem Fall, wenn man diese cached, dann sollte aber auch Änderungen des iodev-Attributen verarbeitet werden.

- Die Änderung zum Eindämmen von "Nahrichten Flut" schaue ich mir noch genauer an und werde sie übernehmen.

- Die Änderung der Rückgabe in onmessage wird vermutlich MQTT-Kompatibilität brechen.

Werde mir morgen weiter ansehen, sonst wird meine Nacht zu kurz ;D
2
Revision 23548: change     : ParseFn gibt jetzt immer [NEXT] zurueck. Verbessertes ...

change     : ParseFn gibt jetzt immer [NEXT] zurueck. Verbessertes Zusammenspiel mit MQTT2-IO

Source: Revision 23548: change     : ParseFn gibt jetzt immer [NEXT] zurueck. Verbessertes ...
3
Hard- und Firmware / Antw:Cul v3 für Fs20 Geräte immer wieder offline
« Letzter Beitrag von vw2audi am Heute um 00:29:51 »
Hallo Ihr lieben,

habe es jetzt auch mit einem HUB mit eigener Stromversorgung versucht.
Naja was soll ich sagen.....
Es lief für 3 Stunden, jetzt ist der Adapter erneut auf Opened gefallen .....
Echt merkwürdig.
An meinem alten System läuft der Cul weiterhin ohne Probleme auch ohne HUB.....

Jemand noch eine Idee?
4
MQTT / Antw:MQTT_GENERIC_BRIDGE - Optimierungen für MQTT2-IO-Module
« Letzter Beitrag von hexenmeister am Heute um 00:24:35 »
@hexenmeister:
Habe mal versucht, den Code von MGB an der Stelle zu verstehen (Parse() und onmessage()), um ggf. unterstützen zu können.

Irgendwie habe ich aber zwei gedankliche Hänger, v.a. im gedanklichen Kontext, dass mehrere MGB aktiv sind:
- wenn bei der ersten MGB kein topic matched, gibt Parse() direkt leer ("") zurück, oder ist das ein Mißverständnis?
- Wenn ein topic matched, wird das erforderliche Array incl. "[NEXT]" zurückgegeben, aber es wird nie geschaut, ob es ggf. noch einen zweiten Match gibt?

Das erstere wäre in unserem Kontext schädlich, oder? Und mehrere MGB würden dann auch (zumindest von MQTT2-IO's) auch nicht "korrekt" beliefert werden, oder?
Und ist das letztere (erster match => raus) wirklich (aus Effizienzgründen?) so beabsichtigt? Weiß im Moment nicht, für was man eine 1:n-Zuordnung praktisch benötigt, aber als "Gruppenschaltung" ist sowas ähnliches z.B. auch in der Tasmota-Firmware vercodet. Will sagen: früher oder später wird ggf. jemand drüber stolpern, man sollte es also wenigstens in der Doku erwähnen...?

Habe auch versucht nachzuvollziehen, was mein Gedankengang damals gewesen ist, ist auch schon etwas her... :o
Irgendwie sehe ich auch keinen Sinn "" zurückzugeben. Habe jetzt hier return ("[NEXT]");
So wie ich das sehe, ist aktuell nicht möglich, mehrere Bridges für den selben(!) IO zu haben - die zweite bekommt nichts.
Es macht eigentlich auch nicht viel Sinn - im Gegensatz zu mehreren Bridges mit verschiedenen IODev.
Ich werde es vermutlich umbauen, um für alle Fälle unerwartete Effekte auszuschliessen.

5
Sonstige Systeme / Antw:Modul 36_ShellyMonitor
« Letzter Beitrag von Paul am Heute um 00:15:58 »
Sorry, aber so umständlich benötige ich es nicht. Die fehlende Daten hole ich mir über HTTPMOD und füge sie mir per userReadings ins Gerät. Dafür brauche ich kein Modul, wo ich dann ein Gerät doppelt anlegen muss.

Und wie sollte ich ein neues Gerät anmelden, er kennt es doch schon (so deute ich den Bildschirmausdruck)

Ich verstehe wirklich den Sinn dieses Moduls nicht.
6
MQTT / Antw:MQTT_GENERIC_BRIDGE - Optimierungen für MQTT2-IO-Module
« Letzter Beitrag von hexenmeister am Heute um 00:14:40 »
In diesem Fall [NEXT] zurueckzuliefern ist unproblematisch, MQTT2_DEVICE macht es bereits, ohne "wenn und aber" => bitte in MQTT_GENERIC_BRIDGE auch einbauen.

done :)
7
Hallo zusammen, 
Ich habe nicht alle 52 Seiten gelesen, daher die Frage ob schon jemand ein RSS auf ein Radio ausgegeben hat. Habe ein Technisat 110 ir mit grafischen Display.
Gruß Roman
8
Sonstige Systeme / Antw:Modul 36_ShellyMonitor
« Letzter Beitrag von gvzdus am Gestern um 23:38:08 »
Probier's aus. Wenn die Werte nicht ankommen, leg' ein zweites Gerät mit der gleichen IP an, und weise ihm das Model "generic" zu. Dann sollte alles ankommen.
9
Sonstige Systeme / Antw:Modul 36_ShellyMonitor
« Letzter Beitrag von Paul am Gestern um 23:35:40 »
Hallo, habe ich es richtig verstanden, dass das Modul nur Readings und das Shelly Modul schreibt, die dort auch aufgeführt sind?

Konkret: ich habe einen Shelly1 mit AddOn Temperatur und Feuchte und bei anderen Modulen auch on/off werden vom Shelly übertragen aber nicht im Shelly Modul übernommen?
10
Anfängerfragen / Antw:Perl Hilfe
« Letzter Beitrag von Kellerkind86 am Gestern um 23:18:32 »
Danke euch.. Hatte davor und dahinter einen Punkt.
Vielen Dank
Seiten: [1] 2 3 ... 10
decade-submarginal