OW2S0SMSGUARD

OW2S0SMSGUARD
Zweck / Funktion
	1-Wire Busmaster mit 2x S0-Interface und USB-Anschluss
Allgemein
Typ	Gerätemodul
Details
Dokumentation	EN / DE
Support (Forum)	https://forum.fhem.de/index.php/topic,28447.0.html
Modulname	00_OW2S0SMSGUARD_2021
Ersteller	Wzut (Forum )
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

	An dieser Seite wird momentan noch gearbeitet.

Einführung

Das Modul "OW2S0SMSGUARD" ermöglicht den direkten Betrieb in fhem. So können leicht zwei Zählerstände erzeugt werden, zum Beispiel für Gas- bzw. Wasserzähler. Positiv berichtet wurde der Betrieb von bis jetzt 32 Sensoren (DS18b20) und einer Gesamtbuslänge (Cat5) von 200 Metern ohne einen Ausfall. Der Vorteil von der SMSGUARD-Lösung: nun ja, einfach an USB anschließen, keine extra Spannungsversorgung. Shop: https://www.sms-guard.org/shop.php Die Firmware wurde von 2014 bis 2020 erweitert.

Version Jahr 2004

Es werden automatisch Slave-Module (Typ "OW2S0SLAVE") für jedes Gerät am Bus angelegt. Das Attribut "disable" wird nicht unterstützt.

Version Jahr 2005

Das Modul bietet auch ein Reset der Zählerstände der beiden S0-Zähler. DS2401 werden nur in der id als Internal angezeigt. Mittels userreadings bekommt man das aber gelöst: userReadings dev1 { InternalVal($NAME,"OW-Dev1","") }

Version Jahr 2021

Es wird keine Slave Device mehr erzeugt, alle OW Teilnehmer sind Readings direkt im Device. Die DS2401 haben als Wert "absent" oder "present", DS18xx ihren aktuellen Temperaturwert. Da die IDs als als nackte Readings etwas unschön sind, hat das Modul ein neues Attribut map_OWIDs bekommen. Damit können die abstrackten IDs direkt in sprechende Namen überführt werden , Bsp: attr <name> map_OWIDs 10D64CBF02080077=Keller,018468411C0000BA=TestDS

Sensoren

Funktionieren:

DS18B20
DS2401
- a) Nachricht wenn ein neuer Teilnehmer hinzukommt (Nachteil, in dem kurzen Moment ist der Busmaster blind, könnte ggf. für kurze Zeit eine andere Nachricht nicht empfangen)
- b) Nachricht wenn ein bestehender Teilnehmer verschwindet (aus meiner Sicht keine Nachteile, der dauernde Stromverbrauch ist minimal)

Funktionieren nicht:

DHT22

Protokoll

Der 1wire-USB-Master kann recht einfach mit einem seriellen Terminal auf Funktion überprüft werden:

serielle Schnittstelle einstellen auf 115200 8-N-1 kein Handshake RTS/CTS, kein On/Off Protokoll
Startbefehl eingeben, damit wird auch die Wandlung im Sensor ausgelöst: $?<CR>
mit angeschlossenen 1wire-Sensoren werden die gefundenen IDs gelistet: $0;o;1080974B020800BA; das „o“ steht für „ok“ und die Checksumme der ID wurde geprüft und ist ok
danach gibt der 1wire-USB-Master die beiden S0-Zählerstände zurück: $S0;0;0;
die Werte der 1-wire Sensoren können nach 1s abgefragt werden mit: $0<CR> ... $63<CR>
danach gibt der 1wire-USB-Master die Daten des Sensors zurück: $0;o;31;00;4B;46;FF;FF;07;10;8D;64; das „o“ steht für „ok“ und die Checksumme (9.Byte) der 8 Datenbytes wurde geprüft und ist ok („n“ wäre „nicht ok“). Die Beschreibung der 8 Datenbytes in Hex ist dem Sensordatenblatt zu entnehmen. Das 10.Byte ist eine Checksumme für die serielle Übertragung (Byte1-9 aufaddiert)