Kleiner Shelly-CoIoT-Sniffer

Begonnen von gvzdus, 31 Dezember 2020, 13:19:20

Vorheriges Thema - Nächstes Thema

gvzdus

Hi, aus Neugier über CoIoT von Allterco / Shelly habe ich mal den folgenden kleinen Sniffer geschrieben, der ausgibt, was die Shellys so per Multicast im Netzwerk rumschnattern.

Man könnte das zum Modul machen und AutoCreate von Geräten oder "Update ohne HTTP-Pollen" für die Shelly-Modul-Fraktion machen. Aber nicht mehr dieses Jahr.

Er erfordert die Installation von IO::Socket::Multicast (ggf. einfach apt-get install libio-socket-multicast-perl).
Außerdem lauscht er auf dem primären Interface, wo ggf. nichts ankommt. Dann Zeile 22/23 ggf. anpassen.

Für *meine* Geräte habe ich die Shelly-CoIoT-Definitionen unten im Code eingepflegt, und für den Shelly 2.5 liebevoll die Definitionen für Relay/Roller-Mode vereinheitlicht.
Es sind jetzt alle Attribute entsprechend der API-CoIoT-Dokumentation von Allterco eingearbeitet, sowie ein wenig Reverse-Engineering von Version 1 (Shelly-Firmware <= 1.6)

Prof. Dr. Peter Henning

Nee, nicht mehr dieses Jahr...

LG

pah

gvzdus

Moin, ich habe alle CoIoT-Beispiele von Shelly unter https://shelly-api-docs.shelly.cloud/docs/coiot/v2/examples/ heruntergeladen, geparsed und zu einem Block vereinheitlicht.

Jetzt sollte der Sniffer also alle dokumentierten CoIoT-Attribute kennen, sofern von Allterco beschrieben.
Außerdem habe ich noch von meinem alten Shelly-Plug-S mit Version 1.6 ein paar Attribute reingepackt, also für "CoIoT Version 1".

Neue Version ist im 1. Beitrag verlinkt.

satprofi

Zitat von: gvzdus am 31 Dezember 2020, 13:19:20Hi, aus Neugier über CoIoT von Allterco / Shelly habe ich mal den folgenden kleinen Sniffer geschrieben, der ausgibt, was die Shellys so per Multicast im Netzwerk rumschnattern.

Man könnte das zum Modul machen und AutoCreate von Geräten oder "Update ohne HTTP-Pollen" für die Shelly-Modul-Fraktion machen. Aber nicht mehr dieses Jahr.

Er erfordert die Installation von IO::Socket::Multicast (ggf. einfach apt-get install libio-socket-multicast-perl).
Außerdem lauscht er auf dem primären Interface, wo ggf. nichts ankommt. Dann Zeile 22/23 ggf. anpassen.

Für *meine* Geräte habe ich die Shelly-CoIoT-Definitionen unten im Code eingepflegt, und für den Shelly 2.5 liebevoll die Definitionen für Relay/Roller-Mode vereinheitlicht.
Es sind jetzt alle Attribute entsprechend der API-CoIoT-Dokumentation von Allterco eingearbeitet, sowie ein wenig Reverse-Engineering von Version 1 (Shelly-Firmware <= 1.6)

hi.
wie startet man das ding?
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

RalfRog

#4
Ist in Perl geschrieben, einfach "$ perl shellysniffer.pl"

Output sieht dann so aus:
14:49:57
Sender: <Shelly-IP>
URI: /cit/s, global_devid = SHSW-PM#E684E5686836#2, validity=2253, serial=5362
cfgChanged = 17
output_0 = 1
input_0 = 1
inputEvent_0 =
inputEventCnt_0 = 219
power_0(W) = 98.58
energy_0(Wmin) = 5030247
overpower_0 = 0
overpowerValue(W) = 0
deviceTemp(C) = 50.85
deviceTemp(F) = 123.52
overtemp = 0

Edit:
Der Zeitstempel in der ersten Zeile ist in der Ausgabe des originalen Sniffers nicht drin. Hatte ich mir im Code ergänzt.
FHEM auf Proxmox VM Bookworm (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen

satprofi

danke.
sehe aber nur die aktoren, sensoren empfängt er nicht.
gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

RalfRog

#6
Öhhh
Was genau meinst du mit Sensoren? Geräte wie Smoke detector etc. habe ich nicht und daher keine Erfahrung damit.

Es wird nicht alles über CoIot geschickt.
Was der Shelly schickt kannst du abfragen http://<IP>/cit/d (ist etwas krytisch) und ist hier beschrieben https://shelly-api-docs.shelly.cloud/gen1/#coiot-protocol-version.

Edit:
Ich meine mit älteren Firmwareversionen hätte http://<IP>/cit/s noch die Daten dazu geliefert. Aktuell geht das offensichtlich nicht mehr.

Edit2:
Möglicherweise sind nicht alle ID's im Code (ab Zeile 54) implementiert.  Der Sniffer ist ja Stand Ende 2020.





FHEM auf Proxmox VM Bookworm (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen

satprofi

gruss
-----------------------------------------------------------------------
beelink miniPC - Fhem 6.x CUL 868, FS20, NetIO230 CUL 433
HMLAN, HM-CC-RT-DN,Homematic Actoren,LD382A,Telegram

RalfRog

Wie gesagt Sensoren hab ich nicht.
Der Sniffer startet ja jetzt -  wenn er keine Anzeige liefert obwohl man CoIoT am Sensor aktivieren kann fehlts vielleicht im Code bzw. diesen Hinweis hattest du gelesen?
Zitat von: gvzdus am 31 Dezember 2020, 13:19:20Außerdem lauscht er auf dem primären Interface, wo ggf. nichts ankommt. Dann Zeile 22/23 ggf. anpassen.


Wenn es dir darum geht zu sehen welche Geräte CoIoT Multicast Pakete liefern kannst du ja auch auf der Schnittstelle sniffen. Z.B. am Raspi mit Ethernet-Interface eth0:
sudo tcpdump   -i eth0 port 5683oder auch mit Daten, JSON-String in ASCII
sudo tcpdump  -A -i eth0 port 5683Sieht für nen 1PM dann so aus:
Zitat... cit.s...    SHSW-PM#E45678245631#2.CX..`..{"G":[[0,9103,17],[0,1101,1],[0,2101,1],[0,2102,""],[0,2103,219],[0,4101,153.85],[0,4103,5114087],[0,6102,0],[0,6109,0.00],[0,3104,54.09],[0,3105,129.36],[0,6101,0]]}  ...
FHEM auf Proxmox VM Bookworm (Futro S740) - nanoCUL, HM-MOD-RPI-PCB und MAX!Cube über LAN
HM- Fensterkontakte, UP-Schalter, Bewegungsmelder und ein Rauchmelder sowie Shelly 3EM, 1PM, PlugS und IT Schaltsteckdosen