Stokerforum
Interface => Interface til varme systemer => Emne startet af: motoz efter Nov 30, 2015, 14:17
-
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.
https://github.com/motoz/nbetest
Use like this:
python client.py -a address -p password functioncode payloador
python client.py -v -a address -p password functioncode payloadfor a more verbose output.
If the address is left out the controller is discovered automatically on the local network
NBE kindly provides a public test box on v7testbox.stokercloud.dk with password 6464111183 that I have used to test the code since I don't (yet) have a V7 controller.
Read some settings from the text box:
python client.py -a v7testbox.stokercloud.dk -p 6464111183 1 boiler.*
You need python installed which can be downloaded here https://www.python.org/downloads/windows/. Both 2.7 and 3.5 work fine.
Ask Jens "BoinkUser" for more details on the protocol if you are interested.
-
Hi Motoz
Thats just splendid 8)
Works like a charm.
Yes, any questions just ask, we also have Android code and Java (PC/Mac/Linux you name it) code, that are free for any interested. Anyone particulary interested in iOS we also have that. But Motoz' code is also a good choice for your preferred platform.
Regards Jens
-
Now I have a V7 box to play with...
Looks like the latest released (not beta) firmware has an older version of the protocol (no sequence numbers). I made a change to the nbetest client so it works with 7.0612 when using the --noseqnum option on the command line:
python client.py --noseqnum -p xxxxxxxxxx 4 *
time=22120
boiler_temp=22.2
smoke_temp=999.9
return_temp=999.9
dhw_temp=999.9
external_temp=999.9
forward_temp=999.9
t7_temp=999.9
distance=0
photo_level=0
shaft_temp=999.9
milli_ampere=0
oxygen=15.4
...
On linux and mac you need to escape the wildcard character '*' (otherwise the shell will expand it to filenames from the current directory):
python client.py --noseqnum -p xxxxxxxxxx 4 \*
This is fun... ;D
-
I fleshed out the test client a bit yesterday. Now there is a 'get' and a 'set' command and a 'raw' command to send raw frames as before.
$ python client.py get
settings/
operating_data/
advanced_data/
consumption_data/
event_log/
$ python client.py get settings
settings/boiler
settings/hot_water
settings/regulation
settings/weather
settings/oxygen
settings/cleaning
settings/hopper
settings/fan
settings/auger
settings/ignition
settings/pump
settings/sun
settings/vacuum
settings/misc
settings/alarm
settings/manual
settings/bbq_smoke
settings/bbq_rotation
settings/bbq_grill
settings/bbq_meat
settings/bbq_afterburner
settings/bbq_div
$ python client.py get settings/auger
settings/auger/forced_run=0
settings/auger/auger_capacity=2200
settings/auger/auto_calculation=1
settings/auger/auger_10=5.72
settings/auger/auger_50=12.9
settings/auger/auger_100=21.9
settings/auger/kw_min=6.0
settings/auger/kw_max=23
settings/auger/runs_minute=6
settings/auger/min_dose=5.0
$ python client.py get settings/auger/auger_capacity
2200
And set:
$ python client.py set settings/auger/auger_capacity 2300
OK
As you may have noticed the controller does not (yet?) check that the password supplied is correct so it can be skipped.
-
Added a small gui to the test code (gui.py)
(http://forumbilder.se/EDF09/nbetestgui.png) (http://forumbilder.se/EDF09/nbetestgui)
https://github.com/motoz/nbetest/archive/master.zip
-
Looks nice, I could not get the client to work though.
My firmware is currently v7.0522, but I dont think it got sofar as to actually talk to it.
C:\Users\MORA\Downloads\nbetest-master>gui.py
Exception in Tkinter callback
Traceback (most recent call last):
File "C:\Particle\Tools\Python27\lib\lib-tk\Tkinter.py", line 1536, in __call_
_
return self.func(*args)
File "C:\Users\MORA\Downloads\nbetest-master\gui.py", line 87, in OnButtonClic
k
self.OnPressEnter(None)
File "C:\Users\MORA\Downloads\nbetest-master\gui.py", line 96, in OnPressEnter
self.text.insert(Tkinter.END, '\n'.join(self.proxy.get(path))+'\n\n')
File "C:\Particle\Tools\Python27\lib\lib-tk\Tkinter.py", line 1898, in __getat
tr__
return getattr(self.tk, attr)
AttributeError: proxy
C:\Users\MORA\Downloads\nbetest-master>client.py -n 1 boiler.*
usage: client.py [-h] [-v] [-a ADDRESS] [-p PASSWORD] [-n] {raw,set,get} ...
client.py: error: invalid choice: '1' (choose from 'raw', 'set', 'get')
C:\Users\MORA\Downloads\nbetest-master>client.py -n get 1 boiler.*
usage: client.py [-h] [-v] [-a ADDRESS] [-p PASSWORD] [-n] {raw,set,get} ...
client.py: error: unrecognized arguments: boiler.*
C:\Users\MORA\Downloads\nbetest-master>client.py -n get 1
Traceback (most recent call last):
File "C:\Users\MORA\Downloads\nbetest-master\client.py", line 61, in <module>
proxy = Proxy.discover(args.password, PORT, seqnums = not args.noseqnum)
File "C:\Users\MORA\Downloads\nbetest-master\protocol.py", line 232, in discov
er
return cls(password, port, addr='<broadcast>', seqnums=seqnums)
File "C:\Users\MORA\Downloads\nbetest-master\protocol.py", line 146, in __init
__
data, server = self.s.recvfrom(4096)
socket.timeout: timed out
C:\Users\MORA\Downloads\nbetest-master>
-
You need at least 7.0612, I don't think there is any UDP protocol support at all in 7.0522. With 7.0612 it should work without sequence numbers, and above that with sequence numbers. The error exceptions are not handled at all in the test client, so when it does not work it just errors out as you noticed. Cool that you are testing it.
-
Updates to v7.0612 today, but what is the correct command to get some data from it?
The python scripts to fail too fast for it to be actual network exchange with a host it needs to detect first.
-
With 7.0612 you have to add the option --noseqnum to the command line, eg:
python client.py --noseqnum getreturns:
settings/
operating_data/
advanced_data/
consumption_data/
event_log/
sw_versions/
info/
and
python client.py --noseqnum get settingsreturn:
settings/boiler/
settings/hot_water/
settings/regulation/
settings/weather/
settings/oxygen/
settings/cleaning/
settings/hopper/
settings/fan/
settings/auger/
settings/ignition/
settings/pump/
settings/sun/
settings/vacuum/
settings/misc/
settings/alarm/
settings/manual/
settings/bbq_smoke/
settings/bbq_rotation/
settings/bbq_grill/
settings/bbq_meat/
settings/bbq_afterburner/
settings/bbq_div/
and python client.py --noseqnum get settings/boiler
returns:
settings/boiler/temp=62
settings/boiler/diff_over=10
settings/boiler/diff_under=5
settings/boiler/reduction=10
settings/boiler/ext_stop_temp=0.0
settings/boiler/ext_stop_diff=1.0
settings/boiler/ext_switch=0
settings/boiler/ext_off_delay=1
settings/boiler/ext_on_delay=1
settings/boiler/timer=0
settings/boiler/monday=000000000000
settings/boiler/tuesday=000000000000
settings/boiler/wednesday=000000000000
settings/boiler/thursday=000000000000
settings/boiler/friday=000000000000
settings/boiler/saturday=000000000000
settings/boiler/sunday=000000000000
python client.py --noseqnum get settings/boiler/tempreturns only the temperature, and so on.
In the gui program you can type eg. 'get settings/boiler' in the input field and click the 'run command' button. The 'seqnums' checkbox need to be unselected on 7.0612
This is only for testing the protocol so far (which probably isn't still final), so it's not that useful yet but something to play with.
-
Very nice and fast O0
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get
settings/
operating_data/
advanced_data/
consumption_data/
event_log/
sw_versions/
info/
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get settings
settings/boiler/
settings/hot_water/
settings/regulation/
settings/weather/
settings/oxygen/
settings/cleaning/
settings/hopper/
settings/fan/
settings/auger/
settings/ignition/
settings/pump/
settings/sun/
settings/vacuum/
settings/misc/
settings/alarm/
settings/manual/
settings/bbq_smoke/
settings/bbq_rotation/
settings/bbq_grill/
settings/bbq_meat/
settings/bbq_afterburner/
settings/bbq_div/
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get settings/boiler
settings/boiler/temp=70
settings/boiler/diff_over=15
settings/boiler/diff_under=10
settings/boiler/reduction=10
settings/boiler/ext_stop_temp=0.0
settings/boiler/ext_stop_diff=1.0
settings/boiler/ext_switch=0
settings/boiler/ext_off_delay=1
settings/boiler/ext_on_delay=0
settings/boiler/timer=0
settings/boiler/monday=220000000002
settings/boiler/tuesday=220000000002
settings/boiler/wednesday=220000000002
settings/boiler/thursday=220000000002
settings/boiler/friday=220000000002
settings/boiler/saturday=220000000002
settings/boiler/sunday=220000000002
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get settings/boiler
temp
70
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get operating_data
operating_data/time=22160
operating_data/boiler_temp=75.9
operating_data/smoke_temp=104.9
operating_data/return_temp=64.5
operating_data/dhw_temp=999.9
operating_data/external_temp=999.9
operating_data/forward_temp=999.9
operating_data/t7_temp=999.9
operating_data/distance=0
operating_data/photo_level=100
operating_data/shaft_temp=42.9
operating_data/milli_ampere=295
operating_data/oxygen=18.9
operating_data/flow1=0
operating_data/flow2=0
operating_data/flow3=0
operating_data/flow4=0
operating_data/power_pct=34
operating_data/power_kw=5.4
operating_data/oxygen_ref=20.9
operating_data/boiler_ref=70.0
operating_data/mean_out_temp=-0.7
operating_data/dhw_ref=0.0
operating_data/forward_ref=0.0
operating_data/sun2_temp=999.9
operating_data/sun_dhw_temp=999.9
operating_data/sun_surplus_temp=999.9
operating_data/air_flow=0
operating_data/content=54
operating_data/state=5
operating_data/substate=0
operating_data/boiler_pump_state=1
operating_data/dhw_valve_state=0
operating_data/house_pump_state=0
operating_data/house_valve_state=0
operating_data/sun_pump_state=0
operating_data/sun_surplus_state=0
operating_data/sun_power_kw=0.0
operating_data/chill_out=-0.7
operating_data/feed_low=4.20
operating_data/feed_medium=21.0
operating_data/feed_high=42.0
operating_data/internet_uptime=100
operating_data/off_on_alarm=1
operating_data/contact1=1
operating_data/contact2=0
operating_data/download_progress=1
operating_data/substate_sec=1
operating_data/corr_low=100.00
operating_data/corr_medium=100.00
operating_data/corr_high=100.00
operating_data/ash_clean=13.4
operating_data/compressor_clean=0.0
operating_data/fan_speed=12
operating_data/exhaust_speed=47
operating_data/output_std=20
operating_data/output_ext=0
operating_data/output_wireless=0
operating_data/city=Tyrsted
operating_data/humidity=92
operating_data/air_pressure=1001
operating_data/wind_speed=1.50
operating_data/wind_direction=30
operating_data/clouds=80
operating_data/outdoor_temp=-2.00
C:\Users\MORA\Downloads\nbetest-master>client.py --noseqnum get operating_data/boiler_temp
75.9
Image shows a Particle Photon subscribed to boiler temp updates from your python script via bash enabling 5second temperature updates :)
-
Godt arbejde, både til Jens og jer andre. UDP er rigtigt smart og det bliver spændende hvad løsninger som det kan blive til i fremtiden :-)
-
After running every minute for a few days it failed today, is there anything I can do to debug it that would be useful ?
:~/nbetest$ ./client.py --noseqnum get operating_data
Traceback (most recent call last):
File "./client.py", line 61, in <module>
proxy = Proxy.discover(args.password, PORT, seqnums = not args.noseqnum)
File "/home/mora/nbetest/protocol.py", line 232, in discover
return cls(password, port, addr='<broadcast>', seqnums=seqnums)
File "/home/mora/nbetest/protocol.py", line 146, in __init__
data, server = self.s.recvfrom(4096)
socket.timeout: timed out
-
Did it fail just once? It says 'timeout', ie no answer. Could be a temporary network problem, or a glitch in the controller. There is no error handling int the test client, so it just quits with an unhandled exception on any problem.
Or did you upgrade the controller firmware?
-
No It has been running in a crontab every minute, but has failed since around 2pm, I only just disabled the crontab since I was getting no sensor data and went to check on it.
Firmware is same as last, it was the latest I could select, v7.0612, not sure if there is a newer one now that I have upgraded.
The error will probably go away if I restart the boiler.
-
I remember Jens said that there was a problem like that in some version, it just died and needed a restart. It's possible it's still in 7.612, I don't remember when it was fixed.
-
Hmm, it still times out after a power cycle on the boiler.
Maybe I should find the IP instead of using discover...
-
That is strange... I have no idea. You could try without discovery, but the controller does not differentiate between broadcast packets and unicast packets so it should not make any difference. You could power cycle your router, maybe downgrade and then upgrade the controller firmware if nothing else helps. Since it worked before it should be possible to return to a working state somehow.
-
Hi,
You need 7.0626 to be sure everything is running smoothly, yes in 7.0612 there are some glitches regarding the communication, so i am quite sure thats the problem. The version is not at the moment of writing available, but you can get it on request.
Regards Jens
-
Is there a timeframe for the new version?
Anyways do I just request here? if so ... I hereby request :)
-
Firmware version 7.0629 (7.0929, 10.0929) and up has some changes in the protocol. For now the changes are in a separate branch (that doesn't work with the old protocol): https://github.com/motoz/nbetest/tree/fwversionx29
-
Now there is support all three protocol versions so far.
V1 works for 7.0612 and 7.0613
V2 is default and works for 7.0614 up to 7.0627
V3 works for 7.0629 and up
eg:
python client.py -V 3 get boiler/settings
V3 needs a correct password to be able to change settings, reading still works without password.
It would be nicer to autodetect the protocol version but since you can't ask the controller for the correct protocol version, it just doesn't answer at all if it's wrong, I figured this is simpler. Anyway who would stay on an old firmware...
-
I started working on a PellMon plugin for V7/V13:
(http://forumbilder.com/images/2016/03/15/ScreenShot2016-03-15at09.07.24.md.png) (http://forumbilder.com/images/2016/03/15/ScreenShot2016-03-15at09.07.24.png)
-
I started working on a PellMon plugin for V7/V13:
(http://forumbilder.com/images/2016/03/15/ScreenShot2016-03-15at09.07.24.md.png) (http://forumbilder.com/images/2016/03/15/ScreenShot2016-03-15at09.07.24.png)
Hi Motoz
Thats cool O0
Regards Jens
-
PellMon with V7/V13 support is is this branch: https://github.com/motoz/PellMon/tree/feature/nbeprotocol
All settings and operating data are available in the webinterface and can be graphed, used in automation scripts, included in the system image and accessed by the command line program pellmoncli. Pellet consumption and silo level graphs should work. PellmonMQTT can be used to publish everything to any decent home automation system with MQTT support. Missing for now is support for the build in log and info messages and a lot of polishing...
-
Hej
Noget nyt på denne front.
vil gerne hente data fra min scottie direkte fra fyret og ikke via stokercloud. samt tænde og slukke fyret via visual basic enten fra stockercloud eller direkte via upd
-
What new stuff are you expecting? The python test program this thread is about has been working fully for a long time and wont get any updates (by me) anymore. If you want to use visual basic you can either implement the protocol yourself in visual basic and then the python code will be a good reference, or you could simply call the python program from visual basic to read/write data from/to your burner with Process.Start. See eg: https://stackoverflow.com/questions/16152531/how-to-run-a-command-prompt-command-with-visual-basic-code
-
Guess ill have to figure this python out.. didnt work in my first attemp..
-
im getting a protocol error from Crypto.publickey import rsa
modulenotfounderror: no module named crypto
-
You need to install the pycrypto python package which is missing from your system. Unfortunately that's a bit cumbersome since you are probably on windows, because that package contains C extensions which needs to be compiled with a c compiler which microsoft doesn't provide by default. Fortunately they made things easier lately by packaging a stripped down version of their compiler that can be downloaded from here: https://www.microsoft.com/en-us/download/details.aspx?id=44266 (Microsoft Visual C++ Compiler for Python 2.7)
After the compiler is installed you should be able to install the pycrypto module with the command:
python -m pip install pycrypto
-
still dont get it.. but thanks for the efford.
Just made at visua.net udp handler. but cant figure out what to send.
im trying to send to this
my controllers ip thoug port 8483
im sending
Get
how does the command expected from the controller look like ? (fx like.. password, get)
is the port right, im listning on the same port as im sending.
hope these simpel questions make sence
-
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:
python client.py get settings/auger
should return something like:
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.
-
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
-
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
-
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
-
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
-
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
-
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
(https://s13.postimg.org/lpsqmficj/Pillefyr_Win_CC.jpg) (https://postimg.org/image/lpsqmficj/)
-
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:
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
-
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.
-
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
-
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!
-
attachment here
-
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?
-
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
-
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.
-
I've mikrotik access point and I run dump directly on them. I've tried sniffing using the mac of the phone as a filter, then I sniffed all traffic... no broadcast at all :( In fact the app didn't find the boiler on local lan but only as "remote".... It will find the boiler only if connected on the wifi lan "generated" by the boiler itself (RTB-XXXXX)
In the meantime I'll try to dump the traffic when attached to this SSID.
-
I'm still waiting for some info from NBE about what changed in the protocol... not much we can do without that.
-
I'm still waiting for some info from NBE about what changed in the protocol... not much we can do without that.
By my side i'm not able to connect to the RTB-XXXXX wifi network :(
do you know the default password?
They told me that it's written on the boiler itself but it doesn't work....
-
Barbaz, can you test the nbetest client from this branch https://github.com/motoz/nbetest/tree/testing/v13 ?
Seems as the v13 controller flips out when it receives a valid frame with a source port higher than 9999, in the testing/v13 branch the source port is set to a free port between 8483 and 9999. The v13 also requires a correct serial number to respond so this is also set in the discovery frame. Would be good to know if this works as I can't test it myself.
-
Barbaz, can you test the nbetest client from this branch https://github.com/motoz/nbetest/tree/testing/v13 ?
Hi motoz! sorry for delay but I didn't have the possibility to test it.... it works! that's fine!
Thank you very much, it seems that you find the problem and now the boiler didn't disconnect anymore.
Some examples:
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxxx get
settings/
operating_data/
advanced_data/
consumption_data/
event_log/
sw_versions/
info/
osmc@osmc:~/nbetest-testing-v13$
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxx get info
Traceback (most recent call last):
File "client.py", line 81, in <module>
args.func(args, proxy)
File "client.py", line 27, in getfunc
l = proxy.get(args.path)
File "/home/osmc/nbetest-testing-v13/protocol.py", line 135, in get
response = self.make_request(9, '')
File "/home/osmc/nbetest-testing-v13/protocol.py", line 176, in make_request
self.response.decode(data)
File "/home/osmc/nbetest-testing-v13/frames.py", line 171, in decode
raise IOError
IOError
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxx get settings
settings/boiler/
settings/hot_water/
settings/regulation/
settings/weather/
settings/weather2/
settings/oxygen/
settings/cleaning/
settings/hopper/
settings/fan/
settings/auger/
settings/ignition/
settings/pump/
settings/sun/
settings/vacuum/
settings/misc/
settings/alarm/
settings/manual/
osmc@osmc:~/nbetest-testing-v13$
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxx get sw_versions
Traceback (most recent call last):
File "client.py", line 81, in <module>
args.func(args, proxy)
File "client.py", line 27, in getfunc
l = proxy.get(args.path)
File "/home/osmc/nbetest-testing-v13/protocol.py", line 129, in get
response = self.make_request(10, '')
File "/home/osmc/nbetest-testing-v13/protocol.py", line 176, in make_request
self.response.decode(data)
File "/home/osmc/nbetest-testing-v13/frames.py", line 171, in decode
raise IOError
IOError
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxxx get sw_versions
Traceback (most recent call last):
File "client.py", line 80, in <module>
with Proxy(args.password, PORT, args.address, args.serial) as proxy:
File "/home/osmc/nbetest-testing-v13/protocol.py", line 75, in __init__
data, server = self.s.recvfrom(4096)
socket.timeout: timed out
osmc@osmc:~/nbetest-testing-v13$
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxxx get advanced_data
Traceback (most recent call last):
File "client.py", line 80, in <module>
with Proxy(args.password, PORT, args.address, args.serial) as proxy:
File "/home/osmc/nbetest-testing-v13/protocol.py", line 75, in __init__
data, server = self.s.recvfrom(4096)
socket.timeout: timed out
as you can see it gives IOerror getting info, advanced_data and sw_versions ... sometimes it returns socket timeout instead
settings seems to work correctly:
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxx -p xxxxx set settings/regulation/boiler_power_min 30
OK
osmc@osmc:~/nbetest-testing-v13$ python client.py -a 192.168.12.22 -s xxxx get settings/regulation/boiler_power_min
30
osmc@osmc:~/nbetest-testing-v13$
thank you a lot!!!!
-
Newbie question - do the use of get commands in the python client affect the data collected to StokerCloud or will that run unhindered despite using the client ?
/Allan
-
It won't affect stokercloud. The connection to stokercloud uses a completely different way of communicating.
-
Great - thank you for the answer - confirms my belief, I think (I expected the Stokercloud to be some kind of push from the controlbox) - it was the mentioning of seqnum (or noseqnum) in some of the client calls that got me a little worried that something might not be stateless ...
-
Yes there is a sequence number, as far as I know the controller doesn't use this field in any way apart from returning it in as is in the response.
PellMon checks that the returned sequence number is the same as the one sent and regards the frame as invalid if not (see https://github.com/motoz/PellMon/blob/3e2511ada9e2cd5715c5c9ad67f45a41ef8d82f3/src/Pellmonsrv/plugins/nbecom/nbeprotocol/frames.py#L177 ), but the nbetest client doesn't check the returned seqnum at all. It's up to the client to increase the sequence number for each request or not, nbetest sends a random number since it is a stateless client.
The protocol is not completely stateless in the controller. Setting changes are rsa encrypted (since they require the password to be transmitted), and that takes a long time to process in the controller (seconds for each frame). To make this work there is an option to set a client specific key for the much simpler xtea protocol. The key is set using rsa encryption, and then the controller remembers the key for that client and can use it to decrypt xtea encrypted setting changes much faster. Due to this the controller only supports a limited number of clients, four or five maybe as I remember it. I think it just drops the key for the oldest 'connection' when the table if full.
The nbetest client doesn't support xtea encryption at all since it is stateless, supporting it would require the xtea key to be stored somewhere. Pellmon sets an xtea key when it connects to the controller and periodically changes it here: https://github.com/motoz/PellMon/blob/3e2511ada9e2cd5715c5c9ad67f45a41ef8d82f3/src/Pellmonsrv/plugins/nbecom/nbeprotocol/protocol.py#L320
The stokercontrol protocol is actually only the controller polling stokercloud with http GET with current data in the query string and commands and setting changes in the response payload.
-
Hi Motoz
Thank you - very comprehensive answer :)
/Allan