KONNEKTING 1-Wire Gateway

[sk73]

Hallo,
könnte der Gatway auch einfache Kontakte unterstützen? z.B. für Fenster am DS2408. oder ist das mögliche Variante des 8Ch Switch?
Gruß
Stefan

[Masifi]

könnte der Gatway auch einfache Kontakte unterstützen? z.B. für Fenster am DS2408. oder ist das mögliche Variante des 8Ch Switch?

Theoretisch gesagt kann das Gateway jedes 1-Wire Device einlesen, was sich an die 1-Wire Spec hält. Dann sollte ein DS2408 auch gehen. Aktuell habe ich diese Möglichkeit nicht auf dem Plan. Aber da die Firmware hier später (wenn sie soweit einigermaßen läuft :-) ) auch veröffentlicht wird, kann jeder der will, diese ändern, erweitern, kürzen, ....
Meine DS2408 implementierung ist aktuell nur zum schalten von LEDs gedacht.

[Masifi]

Ich habe das Problem mit der FW31 gefunden :-)

Es lag an der "FlashAsEEPROM" Lib, diese ist defaultmäßig nur auf 1024 Bytes ausgelegt. In der FW31 überschreiten wir diese Anzahl jetzt. Ich habe die LIB angepasst und im freigegeben Ordner aktualisiert.
Ihr müsst jetzt nur den LIB Ordner aus dem Drive-Ordner kopieren und in eurer Adruino IDE im "Libraries" Ordner, den alten überschreiben

#include "FlashStorage.h"

#ifndef EEPROM_EMULATION_SIZE
#define EEPROM_EMULATION_SIZE [COLOR=#FF0000]1024[/COLOR]
#endif

geändern auf

#include "FlashStorage.h"

#ifndef EEPROM_EMULATION_SIZE
#define EEPROM_EMULATION_SIZE [COLOR=#008000]1324[/COLOR]
#endif

die 1324 habe frei gewählt. Unter Umständen könnte es notwendig sein, bei weiteren Ausbauten der FW, diese noch zusätzlich zu erhöhen.


EDIT: Das heißt: Sisamiwe du kannst jetzt nach dem du die Änderung vorgenommen hast, es noch einmal probieren. Für die Anderen gilt das dann natürlich auch.

[Masifi]

Ich habe nun eine gewisse Anzahl an Rückmeldungen bekommen. Es hat sich gezeigt, dass es unterschiedliche Ergebnisse gab. Entweder alles lief gut und soweit einfach oder es lief so gut wie gar nichts :-(

Nach Rücksprache mit den Testern habe ich mir die ein oder andere HW zurückschicken lassen. Ich habe mir die komischen Verhalten angeschaut und selber festgestellt, dass diese auch zum Teil bei mir auftreten.

Im ersten Moment glaube ich nicht, das es an der HW selber liegt, da die meisten Auffälligkeiten beim Laden der Parameter geschehen. Es scheint so, als ob nicht immer alle Parameter richtig geladen werden.


Aktuell versuche ich daher das SPI Flash auf dem ItsyBitsyM0 in Betrieb zu nehmen. Leider scheitere ich noch beim kompilieren des Codes von Ing-Dom aus dem Thread: https://knx-user-forum.de/forum/proj...90#post1329390
Es könnte sein, das ich die ein oder andere Hilfe von euch benötigen würde.

im meinem Drive Ordner habe ich mal den von mir erstellten Code abgelegt:
https://drive.google.com/drive/folde...da?usp=sharing

Ich bekomme warum auch immer diesen Fehler: FileAsEEPROM.h:91:5: error: 'File' does not name a type

vielleicht hat jemand einen Tipp/Rat :-)

[Masifi]

Dank Ing-Dom Hilfe läuft das SPI Flash nun. Es lag nur daran, dass die neue Adarfruit SPI Lib nicht mit der von SirSysdom zusammen arbeitet. Auf die alte Version 1.0.8 zurück und zack läuft es.

Im Board Manager bin ich für den ItsyBitsyM0 (Adafruit SAMD Boards) auf die aktuellste 1.5.1 gegangen. Vom Gefühl her arbeitet er jetzt ein bisschen besser, zumindest musste ihn seitdem nicht mehr Reseten noch doppel-klicken um in seinen zweiten Bootloader zu kommen.

Aktuell habe ich drei Gateways bei mir am Arbeitsplatz. Werde morgen die SW mal auf allen drei testen und schauen, ob sie sich bei allen drei Gateways auch gleich verhält.
Wenn das der Fall ist, dann geht es ganz normal weiter. Eine etwas verbesserte FW31 wird dann wieder ins Drive Laufwerk gelegt. Um das SPI Flash zu nutzen muss ich noch ein Anleitung schreiben, daher mal schauen wann ich dazu komme.

Da ich gerade immer mehr den Überblick verliere :-) wäre es gut, wenn sich diejenigen die noch eine HW besitzen, mir noch einmal ganz kurz hier oder per PN, den Status durchgeben könntet und auch, ob ihr schon was mit der FW31 gemacht habt und wenn nicht, ob ihr es vor habt.
Falls ihr noch keinen Kontakt mit der FW31 hattet, dann wird es vielleicht besser sein, auf die FW31a zu warten.

Danke dafür und auch für das ganze rumspielen und testen !!!

[Masifi]

Danke für eure Rückmeldungen, die haben mir sehr geholfen.

Fazit:
- Das speichern der GA + GA + Parameter auf dem SPI Flash funktioniert jetzt bei mir auf allen HW-Varianten, drei an der Zahl, ohne Probleme.
- Stränge bis 40m und einer Anzahl von 3 Sensoren mindestens möglich
- Stränge bis 30m und einer Anzahl von 6 Sensoren mindestens möglich
- Ein Strang mit 40m und 11 Sensoren macht aktuell Probleme -> unklar warum es hier zu diesen Auffälligkiten kommt. Falls jemand sein schon bestehenden Strang auf die Länge+ Anzahl verlängern könnte, damit man abprüfen könnte, ob das Verhalten auch hier Auftritt, wäre super. (Wenn das bei jemand geht, dann zuerst mit mir Absprechen)
- Die aktuell verwendete State maschine in FW31 ist instabil -> Änderung in FW31a
- FW30 läuft soweit stabil (wenn man BUS in Ruhe lässt)

Ausblick:
- FW31a update bis spätestens Ende der Woche
- FW32 mit angepaster State Maschine und senden bei Wert-Änderung für alle Sensoren schon in Planung.

[Masifi]

Wäre es für die FW32 denkbar und gewünscht:

- Auf jeden 1-W Channel (CH1, CH2, CH3) je 10 DS18B20 legt
- Das Einlesen der neuen Sensor ID frei zwischen CH1, CH2, CH3 wählen kann (dann kann man CH für CH einlernen)
- Das Einlesen der iButtons frei zwischen CH1, CH2, Ch3 wählen kann
- Die 10 Multisensoren (nur die DS2438 Teile) einzeln pro Multisensor zwischen CH1, CH2, CH3 wählen kann.

!?

Damit könnte man die State maschine optimal auslegen, da man dann die Temp Sensoren zwischen CH1, CH2, CH3 parallel abfragen kann. Bei den DS18B20 muss immer bei 12Bit 750ms gewartet werden bis die Werte zur Verfügung stehen. In dieser Zeit würden die Ibuttons abgefragt werden. Nachdem alle Temp Sensoren abgefragt und gesendet wurden, was dann etwa 10x 1sek benötigt = ~10sek, würde ich einmalig nach neuen IDs suchen, dass sollte relativ schnell gehen. Dann geht es nacheinander weiter mit den Multisensoren mit der Annahme etwa 1sek pro Sensor. Auch hier bei den Wartezeiten kann man nach iButtons suchen und zum Schluss wird wieder einmalig nach neuen IDs gesucht.

Das würde heißen, dass man alle ~20sek aktuelle Werte erhält, bei meiner aktuellen Variante würde es bis zu 1min dauern.

statemaschine.png

[Masifi]

Und ist es für die 10 DS18B20 pro CH notwendig, dass man das Senden bei Wertänderung pro Sensor selber festlegen kann, oder reicht es, dass man pro CH für die jeweiligen Sensoren gemeinsam eine Schwelle festlegt ?!

[ur63]

...oder reicht es, dass man pro CH für die jeweiligen Sensoren gemeinsam eine Schwelle festlegt ?!

Das wäre mir zu wenig Flexibilität.

Deshalb: Individuelle Schwelle je Sensor.

Bin aber momentan nur sehr interessierter Mitleser.

[Sisamiwe]

- Auf jeden 1-W Channel (CH1, CH2, CH3) je 10 DS18B20 legt
- Das Einlesen der neuen Sensor ID frei zwischen CH1, CH2, CH3 wählen kann (dann kann man CH für CH einlernen)
- Das Einlesen der iButtons frei zwischen CH1, CH2, Ch3 wählen kann
- Die 10 Multisensoren (nur die DS2438 Teile) einzeln pro Multisensor zwischen CH1, CH2, CH3 wählen kann.

Das sollte erstmal alle Bedarfe abdecken, da es maximale Flexibilität bietet.

Und ist es für die 10 DS18B20 pro CH notwendig, dass man das Senden bei Wertänderung pro Sensor selber festlegen kann, oder reicht es, dass man pro CH für die jeweiligen Sensoren gemeinsam eine Schwelle festlegt ?!

Das würde zumindest mir reichen.

[Masifi]

Danke an Sisamiwe, wir haben gerade die FW31 in Betrieb genommen und festgestellt, dass im XML File noch was nicht gepasst hast. Also an alle die schon mal das XML File in Suite eingelesen haben, müssen dieses wieder entfernen und löschen und das neu abgelegte File verwenden!

[Masifi]

Ich habe auch mal eine erste Version der FW32 mit der angepassten State maschine abgelegt. Falls jemand diese auch mal testen will nur zu, aber kein Zwang. Bevor ihr aber von FW31 auf FW32 geht, dann am besten noch mal das SPI Flash formatieren und dann alles mit FW32 neu Programmieren.
Werde übers Wochenende kaum erreichbar sein, daher viel Spaß :-)

[Masifi]

Was aber noch Cool wäre, wenn jemand von den Testern einfach mal einen funktionierenden Bus einfach noch zusätzlich erweitert mit Kabellänge + Sensoren, damit wir etwas mehr Klarheit bekommen, was technisch so möglich ist. Danke dafür !!!!
Was dabei auch wichtig ist, ist das schaut wie sich das Gateway verhält, wenn es zuviel Sensoren/ein zu Langer Bus anliegt. Kommt gar nichts mehr, oder kommt eine Debug-Ausgabe, das der Bus einen "short" hat. Daher auch vorteilhaft, wenn ihr das alles im Debug-Modus macht, dann seht ihr viel schneller was eigentlich Sache ist.
Auch da Danke dafür, falls jemand dafür Zeit hat !!!

[Masifi]

Mal ein weiterer Zwischenstand was die ersten Untersuchungen gezeigt haben:

Dieser Aufbau läuft aktuell mit er neuesten FW32.

CH1:
Gateway --> 15m YSYT 2x2x0,8 --> Sternknoten -->
- 8m NYM 5x1,5 mit 1 DS18B20
- 8m NYM 5x1,5 mit 1 DS18B20
- 5m NYM 5x1,5 mit 1 DS18B20
- 8m NYM 5x1,5 mit 1 DS18B20

CH2:
Gateway --> Sternkonten -->
- 20m YSTY 2x2x0,8 mit 1x DS18B20
- 15m YSTY 2x2x0,8 mit 1x DS18B20
- 2m Sensorleitung mit 1x DS18B20


CH3:
Gateway 8m --> 2x2x0,8 --> Sternkonten -->
--> 14m NYM 5x1,5 zum MS und DS18B20
--> 15m NYM 5x1,5 zum DS18B20
--> 2m zum DS18B20
--> 2m zum DS18B20
--> 2m zum DS18B20

Ja, hier steht NYM und nein man muss das jetzt nicht kommentieren. Es ging leider nur so und es zeigt auch, dass mit dem richtigen Kabel noch mehr möglich sein wird!

[Masifi]

So da es sich langsam zeigt, dass die HW des 1-Wire Gateways seinen Zweck erfüllt, können sich die Interessenten einfach mal bei mir melden, damit ich einen Überblick bekomme, was ich denn so an Bauteilen bestellen muss.
Ein wichtiger Punkt wäre, ob ihr auch interesse an so einem iButton LED SW habt, wenn ja, dann wäre das eine andere Platine mit anderen Bauteilen und ~1-2€ extra

Genaue Infos über die Bausatzvarianten findet ihr hier: https://knx-user-forum.de/forum/proj...35#post1356335

wichtige Hinweise:
- ihr setzt das Device nur als Testdevice ein, wenn ihr es im Dauereinsatzbetreiben wollt, dann auf eure Verantwortung
- Das Device hat zwar eine galvanische Trennung zwischen KNX und 1-WIRE(5V), aber in wie weit diese ein Übersprechen im Fehlerfall verhindert, kann ich nicht und werde ich nicht testen. Daher sorgt dafür, dass euer 1-Wire Bus eine ausreichende räumliche Trennung zu euerm "Hochspannungsnetz" hat. Schutzkleinspannung <60V DC sollten kein Problem sein. Bei 230V AC solltet ihr genauso wie bei eurem KNX die selben Vorkehrungen treffen.
- Die 1-Wire Eingänge sollten bis 24V geschützt sein und auch gegen einen ESD-Impuls. Falls jemand dazu mehr wissen will, muss nach MAX9940 schauen, dieser Baustein wurde bestückt.
- Auf der 5V Sensorversorgung solltet ihr sicherstellen, dass von Außen keine Rückströme in das Gateway fließen (z.B. wenn jemand ausversehen 24V an die 5V Ausgänge anschließt -> kann zu einem Defekt führen.
- Aktuell müssen alle Sensoren mit Power (meistens 5V) versorgt werden, ein parasitärer Modus ist aktuell noch nicht umgesetzt.

Bei weiteren Fragen, schreibt mich einfach an.