Velbus software

I’m trying to change my server application (which connects to the serial port and allowed for 1 client to connect) to connect to your server/gateway and the serial port (in fact replacing your client)… This works most of the time (I 'm able to read and write - using your perl script for this) but every now and then it crashes :angry: (memory leak I guess), but I didn’t have the time to figure this out yet.

Anyway I monitored the data coming in over the serial port and the data your server-app transfers and I’ve got no data-loss for now. Every now and then I get a “framing error” from your server, but still all data is transferred.
Where exactly did you notice data-loss in your tests (with high throughput on the bus)? Was it at your clients-side or at the server-side?

I took a look at your client and I wondered if it would be better to use a separate thread for reading data?
I use a “readerthread” and a “writerthread” for reading and writing from/to the serial port and I never had any problems so far. (You mentioned using flow control in a previous message: I don’t use flow control…)

When I fix the crashes in my app I’ll let you know, maybe you can test it with your test cases, if you’re interested… (It’s written in C++).

Best practice would indeed be to use a seperate thread for the reader to handle incoming data. The VelbusLink uses two seperate threads, one for reading, one for writing. The writing thread queues packets and sends them at intervals, and making sure there is about 60ms between each packet.

You’re probably getting data loss because you assume data will be received per 8 bytes, while in fact an arbitrary buffer size of (for example) 20 bytes could be received containing multiple packets. The code as it is now will only examine the first 8 bytes and discard the rest.

Anyway, nice to have some linux support :slight_smile:

Hello,
the data loss is idd in the client app and the intention was to have seperate treads but for now I didn’t have the time to have that one fixed (doing some rebuildings at my home). The problem is idd that when receiving data it blocks the others from receiving.

The “frame error” in the server was just for debugging purposes and needs to be refined. At the moment it only checks if there 's an 0x4 at the end of the frame without any further aruments. Actually, that part of the code ins’t really needed because te client has to cut the frames in pieces. This was just a way t let “simpler” app’s works to just by receiving frame by frame.

I’m idd interrested to have a look at your app. It would be great having a stable totaly working linux velbusserver and from there lots of others apps can be easely connected to the system.

hello,

made a new version of the client, now everything works perfect. Did a Client/parent combination so 2 different processes to receive/send the data. The client receives the data from the network, cut it into signle frames and wait for 60ms. The parent receives from the comport (in my case the vmbusb) and put it directly on the network without any further handling of cutting etc.

Also cleaned-up the source a bit :smiley:

The new source can be found @ the above link (client_velbus).

usage: ./client_velbus /dev/… the standard device is /dev/ttyACM0, so when no option is given, this is the interface.
The server is still the same, it listens on port 3788 and sends the data to all connected clients on port 3788.

This how a setup should (could) be:
http://leachy.homeip.net/velbus/my_velbus_philosophy.png

I updated my code so that it works with jeroends’ server. I think i also fixed the memory leaks (been running here for a couple of days).

My setup is as follows: the velbusinterface connects to the fysical interface (in my case a vmb1rs) by autodetecting a valid velbusinterface (checks all /dev/ttyS* and /dev/ttyUSB* - so a change would be needed to autodetect the ttyACM* devices). This velbusinterface also connects to the jeroends-server.

The I have a couple of clients (pirmanager and blindmanager). Pirmanager handles my orientation lighting (LEDs go on when movement is detected). Blindmanager handles my blinds.
These apps connect both to a small daemon (ephemerisd) I wrote. This daemon periodically calculates the sunrise and sunset times. Periodically pirmanager and blindmanager connect to ephemerisd to fetch these sunset and sunrise times. Underway an offset can be taken into account (by means of configfiles).

This picture shows my setup:

http://users.edpnet.be/dewittedecrock/velbus-setup.jpg

Code can be found at users.edpnet.be/dewittedecrock
Makefiles are included… In case you want to test you should copy the contents of the etc-directory to your /etc directory (this is where the programs look for their configfiles).

PS: All apps are able to run as a daemon. It may be interesting to run in foreground for debugging purposes (see configfiles)

Have fun.

hello,
I’ve made a new version a my server/client soft. The problem with the previous versin was that when receiving not the full frames, the software would simply rejects them (because it was frm the point that a frame always came in at least at once). Now the soft handles byte par byte and does a frame check.
The new program also combines the two previous programs (client/server) and acts as deamon. It has verbose modes, just the more “-v”'s you place in the comment line, the more you get (till six times).

source can be downloaded at the following link: leachy.homeip.net/velbus/velserv.c
compiles with: gcc -o velserv velserv.c -lpthread

Usage: velserv -csfvhV] -d DEVICE] -a ADDRESS] -p PORT]
-s --server act as server only, gateway will be disabled
when in server mode, the address is always 127.0.0.1
-c --client act as client only, server wil be disabled
-d --device INTERFACE device where the Velbus interface is connected to
default device is: /dev/ttyACM0
-a --address HOST IP address or hostname where to connect to as client
default is 127.0.0.1
-p --port PORT port where to connect
default is 3788
-f --foreground do not run in background
-v --verbose verbose operation, repeat for debugging output
1 general debug, 2-3 com to socket debug, 4-6 server socket debug
-h --help print this help and exit
-V --version print version information and exit

enjoy …

1 Like

Hello Jeroen,

I’m running a Velbus configuration for more than a year with a VMB1USB - USB-interface instead of the VMB1RS.
Does your code support also input and commands from this USB interface card or can you easily make it support this interface.

I would like to integrate your software into my QNAP NAS server. My TS-239 runs Linux and has 2 USB connectors. I hope it can detect the VMB1USB interface.

What component are you using for the PIR detection and how did you technically connect it to the Velbus?
Do you plan to expand the features of your server-clinet application with a web server? Would be handy to have a GUI or website available to configure and monitor everything.

Best Regards,

Geert :slight_smile:

Hello,
I’m also using the vmb1usb as main interface at the moment but I’m playing with the vmbrsusb and a serial over ethernet interface (mdl-s2e from ti) to create a standalone solution.
I think you 'll already asked that questing about your qnap server ans as far as I can see the problem there is that the serial drivers aren’t loaded in the kernel. So there are 2 things you can do, recompile your kernel or wait when I’m ready with the serial to ethernet interface. With recompiling your kernel you’ll have to know exactly what your doing (in the means of setting the options and choosing the right kernel). Maybe you could ask the guys of qnap to give you a help or search the internet for more info about the right kernel etc.
As for a GUI. My plans are to either develop a small standalone touchscreen (focus.ti.com/docs/toolsw/folders/print/rdk-idm-sbc.html or noritake-itron.com/tft/) or a small application with a mini touchscreen (ex. mimomonitors.com/products/mimo-720-s) because I find a big touchscreen ugly and hard to integrate. A screen of 3,5" fits perfectly in a bticino housing.

Hope you 've a answer on this…

Jeroen

Hmm, this is an interesting solution, this would mean that any application on the network can connect to a certain ip/port to comunicate with the vellbus interface. Would be really cool to have this working, this way you could integrate vellbus complete with your home network without the need of having a pc on all the time.

Looking forward to see this working.

Idd, that’s the intention. For the moment all I got from the interface is some garbage on my socket, only when using the velbus interface. When using a simple com program (ie hyperterm) everything works fine, maybe a level mismatch. to be continued …

To “Legigi”:
another solution could be to reinstall your qnap to ie. sme server (contribs.org). Doing so will open a wide port for u to use a whole lot other software on your qnap. If I see at the specs of the T-239, it uses either an ide disk on module (normal t-239) or an usb stick in another hardware form (t-239II) as boot disk. So it is easy to replace by another disk or stick to experiment with it. By installing sme server you can to the same and even more (I don’t know what the use of your t-239 is at the moment). The processor and ram are enough to let it work smoothly. In my case a fit pc is used with an amd 500Mhz and only 256Mb ram running as web, ftp, vpn, network host, router, firewall and velbus 8) server, everything logged and monitored without a glitch, just a thought …

[quote=“jeroends”]Idd, that’s the intention. For the moment all I got from the interface is some garbage on my socket, only when using the velbus interface. When using a simple com program (ie hyperterm) everything works fine, maybe a level mismatch. to be continued …
[/quote]

wierd that it works one way, don’t think its a level mismatch because it would fail both ways then.

anyway gonna start playing with it, but i ordered a lantronix (lantronix.com/device-networking/external-device-servers/xpress-dr_dr-iap.html) din module to integrate it nicely next to the vmbrsusb module

That looks like a nice interface indeed but a bit pricy. I’d like to keep the costs as low as possible. For that amount I’ve got a mini pc in din format doing a bit more that just converting my signals …

ok,
I think I figured out what I was doing wrong (all the time). Like always I read the manualls half/half and as a result of that I read some signals wrong. With fast reading I always read RTS/CTS, so the thought was that I needed handshaking, but it is RTS/DTR (both outputs from the terminal side) that I need to feed in fact the RS232 pump (galvanic isolated). That’s the reason I was getting a lot of garbage out of the interface.
Now my question: what are the minimum levels I need? Normally RTS and DTR are +/-15v but is it enough to have one side grounded and the other side at + or - 15v? I don’t have an extra out on my interface (only RTC/CTS) that’s why I ask this.

update: apparently it’s enough to tei DTR to th ground and put RTS high. the interfcae now transmits every byte as it should be, only some frame checking has to be implemented and everything should be fine :slight_smile:

great,

so by connecting to a specifick ip:port combo you are able to comunicate with the vellbus interface?
thats exactly what i’m trying to acomplish.

I was planning to create an interface to control everything with a foxboard G20 and an oled display.

at the moment I’m brainstorming about a new idea (the serial/tcp has to wait, it’s not a feature I need for now since I’m doing this already with my linux server).
What I was thinking is create an application on a standalone display. The reason why I’d came on this idea is because my wife simply can’t manage the heating (right :laughing: ), but i understand her because the vmb1tc isn’t the most user friendly interface …
After searching the inet for a while and had a lot of possibilities coonsidered I think the following are the most interresting options:
the smartq V7 and the smartq V5. Why are the are very interresting (in my opinion) they are both practicly the same (the one a 7" display the other a 4,3"), they support linux, wince 6.0 and andriod and they are pretty cheap (the 5 about a 130 and the 7 abut an 170€). The only things where I’m not out is wheither to take a 5 or a 7 version. The 5 can be dismanteld and can fit in a bticino box (with some minor adjustments to do), the 7 has a stand and can be putted at any place you’d like.

But the biggest question of all: what program language to use?!? I was thinking about qt4 but thatcI’ve to learn from 0.
Anyone any suggestions or willing to participate or has some input?
I like programming but my graphical scins aren’t that well …

Hi Jeroen,

I was thinking to do the same and use some kind of web interface.
This way it would be device and OS independent
and also it would be fairly easy to implement.

that’s true but what about the dynamic interface (I’ve never worked with flash) and whay about the connection with the bus? Does a web app has direct access to hardware interfaces (a network port I know is possible to do but not everybody owns a server)?
Qt is also platform independant and can be written in C/C++.

making the interface dynamic enough maybe the hardest part,
but I think it should be possible.
Personally I wouldn’t use flash because I don’t really like it and it brings with it an extra layer of complexity/compatability etc. without real added value.
Using some ajax and javascript like jquery should do the trick.

the webapp should send only relative small request to the server which will do te real communication to the bus.
Several setups are possible,
a standalone home written program can have a direct web interface (after all it is just writing and reading some data on tcp port 80)
or a more traditional setup is possible with a real webserver (fe appache and php)
which can write and read in a database.
Another program should communicate with the bus and update/use this data.
or instead of a database a direct network link is possible.
I believe you already wrote some application able to convert the bus to tcpIP,
it should be rather easy to have a webpage sending something to this port;

And indeed you are correct that a server is needed,
but that shouldn’t be a bottleneck as only a very small pc is needed and at some point
you have to connect all your devices to the bus anyway.
(I suspect you don’t want to connect them all directly)

I wrote idd a server program, but I don’t see everyone install a server. The solution to that point is the interface I’m creating (velbus to tcp in hardwareform) but that interface can’t receive multiple connections. An other solution to that problem could be a mini embedded bord wich run the server soft I’ve written above (can receive as much connections the system is capable to).

The displays I’ve found have a wifi connection but both do also have a serial port on board wich can be used t interface directly to the bus (but requires a hardware modification wich is not always evident for everyone). Interfacing directly could be interresting when ie building the 4.3 version in wall (more modifications needed but looks nicer).
Thus when developping I think both options must be left to the end user but shouldn’t be the biggest problem.

About applications in a webbrowsers, I’m not very keen on them. The reason is that you’ll face the fact that there are to much differences between the most browsers (the one feature will not always work in the other and so on).
Now, java can also be ran out of a browser … Don’t know if ajax can (never used it before).

An other possebility could be that Stijnen Soltutions came up with a (stripped) version of their program wich run ie unther android, linux or wince and without the use of a main program wich runs unther windows (I’m not very happy with that kind of setups).

Bit more brainstorming to do I think, other ideas are always welcome …

Stijnen Soltutions should lower the price of their software, they would be selling more of them if it was around 90 or 100 euros HT.