V7/V13 UDP protocol client in python

[motoz]

Did you try to install the compiler package from microsoft? After that you should be able to enter the above in a command prompt window and it should 'just work'  (but I don't have a windows computer to test with). I suppose you already installed python 2.7 and have that working? Then for instance this:

Kode: [Vælg]

python client.py get settings/auger
should return something like:

Kode: [Vælg]

settings/auger/forced_run=0
settings/auger/auger_capacity=1502
settings/auger/auto_calculation=1
settings/auger/auger_10=6.99
settings/auger/auger_50=18.2
settings/auger/auger_100=32.1
settings/auger/kw_min=5.0
settings/auger/kw_max=23
settings/auger/runs_minute=6
settings/auger/min_dose=5.0

The protocol is fairly involved and binary, you won't get anything back by sending a text string to the controller. Either you can find out what to send by reading my python code, or you can ask Jens for the protocol specification (excel file), which describes how to compose a valid request frame and interpret  the reponse.

[Alfie]

Hej

Jeg ved ikke om det her er den "rigtige" tråd, at spøge om min udfordring i. Jeg har et Siemens S7-300 PLC system med tilhørende Siemens WinCC HMI applikation. Udfordringen er, at kunne interagere med "V7" styringen, da den eksisterende varmestyring ligger i Siemens systemet. WinCC kan afvikle VB spript og jeg tænker at kunne integrere noget af det der i denne tråd er skrevet om, men har desværre ikke helt styr på, hvordan det kunne gøres. Ønsker kunne være, at kunne læse temperatur værdier, skriver setpunkts ændringer, tænde/slukke for brænderen og se status generelt. Har i forslag til, hvordan jeg ville kunne komme videre?

På forhånd mange tak
Alf

[MHES]

Hej Alf,

Med en Siemems S7-300 kan du reelt lave det du ønsker, men....
Du skal kende meget til Ethernet kommunikation og opbygning/decifrering af telegrammer for at kunne løse opgaven.
Du har ikke nogen hjælpeværktøjer i Siemens pakken, så du skal lave alt fra grunden.

I praksis er det ikke realistisk, medmindre du er en ørn til Ethernetkommunikation på low-level i Siemens verdenen.

Hilsen
Michael

Hej

Jeg ved ikke om det her er den "rigtige" tråd, at spøge om min udfordring i. Jeg har et Siemens S7-300 PLC system med tilhørende Siemens WinCC HMI applikation. Udfordringen er, at kunne interagere med "V7" styringen, da den eksisterende varmestyring ligger i Siemens systemet. WinCC kan afvikle VB spript og jeg tænker at kunne integrere noget af det der i denne tråd er skrevet om, men har desværre ikke helt styr på, hvordan det kunne gøres. Ønsker kunne være, at kunne læse temperatur værdier, skriver setpunkts ændringer, tænde/slukke for brænderen og se status generelt. Har i forslag til, hvordan jeg ville kunne komme videre?

På forhånd mange tak
Alf

[Alfie]

Hej Michael,

Super mange tak for svar:-)
Måske jeg har misforstået noget. Jeg kan se her i tråden, at man kan "eksekvere" filen client.py, fra phyton med argumenter, hvor så der skulle bliver svaret fra styeringen i en eller anden udformning. Der er ligeledes skrevet noget omkring, at eksekvere phyton fra Visual Basic, er det korrekt?
Jeg kender desværre ikke noget til phyton og har i nogen udstrækning brug for hjælp til, at kunne udfylde argumenter/fil med f.eks. adresse, password med mere. Hvis dette kan gøres, kan VB hente og sende data til WinCC.

Hilsen
Alf

[MHES]

Hej Alf,

Phyton er er et programmeringssprog/-værktøj der typisk afvikles under Linux eller Unix, men som også kan fungere under Windows med lidt ekstra gejl.
Du får nok ikke afviklet Phyton på din Siemens S7-300 

Hilsen
Michael

Hej Michael,

Super mange tak for svar:-)
Måske jeg har misforstået noget. Jeg kan se her i tråden, at man kan "eksekvere" filen client.py, fra phyton med argumenter, hvor så der skulle bliver svaret fra styeringen i en eller anden udformning. Der er ligeledes skrevet noget omkring, at eksekvere phyton fra Visual Basic, er det korrekt?
Jeg kender desværre ikke noget til phyton og har i nogen udstrækning brug for hjælp til, at kunne udfylde argumenter/fil med f.eks. adresse, password med mere. Hvis dette kan gøres, kan VB hente og sende data til WinCC.

Hilsen
Alf

[Alfie]

Hej Michael,

Jeg er ved at forstå syntax'en ved at eksekvere phyton filer fra comandoprmten i Windows og det ser lovende ud. Dette skulle umiddelbart også sagtens kunne lade sig gøre fra Visual Basic og derved også fra WinCC. Jeg er klar over, at PLC'en ikke kan afvikle phyton og det har heller ikke været meningen. WinCC er det grafiske interface til PLC'en, så på den måde kan jeg hente og sende data til PLC'en, hvis det er det jeg vil.

Mvh
Alf

[Alfie]

Det er for længe siden lykkedes mig, at få en komunikation op til styringen, som kører via pyhton jobs i Visual Basic.
Men jeg savner noget mere sofistikeret komunikation, som f. eks OPC, Modbus eller Profibus. Umiddelbart ville tro, at det snilt ville kunne lade sig gøre med Modbus TCP fra styringen, men det kræver, at det bliver indkorpureret. Er der nogle der ved, om det i fremtiden kunne blive en mulighed?
Mvh
Alf

[barbaz]

Jens told me that the new UDP protocol for local communication with the V7/13 box is nearing final, so if you have an updated V7 box you can try to talk to it with a test program I put up on github. It's written in python so it works on windows/mac/linux (and with some effort http://pythoncentral.io/python-for-android-the-scripting-layer-sl4a/ on android).  The test code implements a simple command line client that sends one request to the controller and prints the response.

Hi motoz,
I've tried your software but wihtout luck
I'm using an RTB with V13 controller version, what I achieve is socket timeout error, like this:

Kode: [Vælg]

root@osmc:~/nbetest-master# ./client.py -vvvvv --address 192.168.12.22 --password 4444444444 get settings/
Traceback (most recent call last):
  File "./client.py", line 78, in <module>
    proxy = Proxy(args.password, PORT, args.address)
  File "/root/nbetest-master/protocol.py", line 52, in __init__
    data, server = self.s.recvfrom(4096)
socket.timeout: timed out
root@osmc:~/nbetest-master# ./client.py -vvvvv  --password 44444 get settings/
Traceback (most recent call last):
  File "./client.py", line 76, in <module>
    proxy = Proxy.discover(args.password, PORT)
  File "/root/nbetest-master/protocol.py", line 163, in discover
    return cls(password, port, addr='<broadcast>')
  File "/root/nbetest-master/protocol.py", line 52, in __init__
    data, server = self.s.recvfrom(4096)
socket.timeout: timed out
root@osmc:~/nbetest-master# ./client.py --password 4444444 get settings/
Traceback (most recent call last):
  File "./client.py", line 76, in <module>
    proxy = Proxy.discover(args.password, PORT)
  File "/root/nbetest-master/protocol.py", line 163, in discover
    return cls(password, port, addr='<broadcast>')
  File "/root/nbetest-master/protocol.py", line 52, in __init__
    data, server = self.s.recvfrom(4096)
socket.timeout: timed out
root@osmc:~/nbetest-master#


both with address and broadcast, and with and without password...
Can you please help me?

Thank you very much for your support!
Have a nice day

[motoz]

No idea really, I verified that the nbetest client still works with my V7 (but I'm not on the latest version of the V7 firmware). I get the exact same error traceback when I point it to a non-existent ip, otherwise correct ip or autodiscover works fine.

It's possible that that the V13 protocol has diverged from how it works in V7, I think I saw a mention in a forum post that there are now different android apps for V7 and V13.

[barbaz]

Hello,
thank you for your reply.
Just to be sure I've tried with an amd64 device (before it was a raspberry), version 2 and version 3 of python but still the same error. And also the same error pointing to the ip or leaving it broadcast.

Is there any chance to know if protocol is changed?

thanks

[barbaz]

a big update....
I've noticed that whenever I run the client.py (both broadcast or ip) suddenly the boiler disconnect from the access point (I've an RTB that it's only wifi).
And in fact the ip is not reachable, after some seconds it reconnects and I can ping it again. If I start pellmon with nbecom it continuously connect and diconnect....
D you have any idea why is this happening?

In the meantime I tried to sniff the traffic... the only packet that it receives from raspberry it's a discover.
I'm attaching it here, maybe can be helpful...


Thank you for your support!

[barbaz]

attachment here

[motoz]

According to Jens (boinkuser) the base protocol is the same, so you should get a response, but there is an new field in the response so neither nbetest/nor pellmon would likely work. But since you get no response and the frame trips up the controller in some way it seems there is something going on here. I suppose you can't easily arrange to get a capture of the discovery frame from the official app?

[barbaz]

Hi was able only to dump packet sent to cloud from my phone. Can be interested also  this?
I've tried with the app do discover devices in lan but I didn't dump any UDP packet sent to broadcast, is this normal?
Or you need packet dumped when the smartphone is directly connected to RTB wifi?

Thank you very much

[motoz]

The communication between the app and the stokercloud server is not interesting. I would assume that the app<->controller communication is the same regardless of which network it's connected to (internal or router), so it wouldn't make any difference. The discovery should begin with a broadcast frame, how are you capturing the traffic? I've never tried capturing wlan traffic, here are some options https://stackoverflow.com/questions/9555403/capturing-mobile-phone-traffic-on-wireshark.

Let's see if we get any more info from Jens.