The server now has the following features:
- Adding, removing and modifying devices,
- Auto discovery on USB ports (windows and raspberry)
- Automatic loading of attached peripheral drivers (the server gets the product and vendor id’s).
- When the peripheral driver is loaded, the server query’s the peripheral for the software running on the peripheral, and loads the software driver.
- This only works for the arduino uno at the moment because this is the only known vendor and product id, it opens a connection (8n1 57600 baud) to the attached arduino device on USB and sends the string “NID” to receive a response with the driver id for the software on the chip.
- But basically taken, the server can communicate with every com port peripheral running at 8n1 57600 baud. as long there are drivers written for it.
- The server loads all the added devices for the loaded driver.
- The server runs system events based on time and based on sunset and sunrise, with this i set the system states morning, afternoon evening and midnight.
- The system events can run commands, so my lights in the house turn on at sunset.
- The server knows locations, like master bedroom, living room etc..
- The server knows of device categories (lights, heating etc…)
- The server does a sort of client authentication when a new client connects you must approve this on the server console (can be disabled)
- The server has a limited web interface (screenshots)
- The server supports I2C in the same way as usb, only without auto discovery and device software probe.
- The server supports serial communications through the serial pins of the arduino.
- The server also supports usb serial connections on windows.
- The server is when it comes to devices “dumb”. Devices are created by they’re xml configurations and device drivers.
- The server has a partial package support, peripheral/driver/device drivers can be installed through packages (although this now is editing xml by hand)
- The web interface is ALWAYS in sync with the devices.
- Controlling devices, the web interface is build by the device xml declaration.
As you can see, there is still A LOT to be done. Although this gives already some nice stuff that can be done, for example:
- I’ve made a little 433Mhz sender which supports an SELECTREMOTE having two of these receivers have me created two devices in the server and controlling them.
- Everything that is based on I2C can be attached (as long there is a device driver for it which runs the I2C commands for that device at a specific address).
As said, devices are created by they’re device XML. This specification is not limited to device types, but on how you control a device. Device controls are being placed in groups, so you can have a group named “Light actions”, “power actions”, etc.. Some device xml tags below:
- togglebutton: creates a choice in the web interface, for example: yes/no, on/off, etc…
- button: creates a single button.
- colorpicker: creates a color picker, include the button within the color picker to set an action for a color, something like: “set direct”, “fade to color”, etc…
- data: creates just a label and field for incomming data non editable.
- Every device must have a default predefined location field, otherwise the server does not know which location your device is, and will not be added to the system.
So, enough about the server at the moment, some stuff about the java client now.
The java client
The client is as “smart” as it is as “dumb” as the web interface of the server. The client builds it’s device controls just like te web interface does. Where the web interface just shows minimal stuff because it primarily is not designed to control, the client is. Some features:
- Modifying the system state.
- Displaying time and date,
- Shows devices base on they’re location and creates a favorites list.
- Builds all the controls defined in the device xml and does not care what type of device it is. it categories on the given device category in the server.
- But despite being “dumb” it does graphing of device’s data types (as described in the device data xml tag).
- The client supports default and logarithmic datatypes.
- Graphs are device category based.
- Light measurements are based on LUX, so there is a lux graph where all the light measurements can be displayed, which is a logarithmic graph
- Temperature measurements are just like LUX measurements ready to plot in the Temperature graph
- The client supports auto scaling as long the ratio’s are 16:9 it displays correctly (despite some work that still has to be done). So it looks exactly the same on 1280*720 as it does on 1920*1080.
- It runs on windows and on the raspberry pi (with jdk1.8).
Well this is a “small” progress list. There are a lot more functions already build in the server and the client. But because of the long time of not posting, better something then nothing.
I have attached some photo’s of my “test” setup:
The “Server”. IT is hanging on a wall, it has one of the first adafruit Pi Cobbler. The prototype board is being fed by an 2Amp 5V “regulated” adapter. It feeds the Raspberry pi (through the usb adapter), The atmega328 attached and the 433Mhz transmitter. It also delivers 5 volt to the I2C bus for extending the length of the I2C range. The arduino software base Atmega 328 is connected to a logic level convertor because the pi serial pins are connected to the atmega serial pins
Here a little test setup for an I2C test device. It is attached to 16 Meter of cat 5 cable. This cable sits between the pi and the Arduino. The I2C is pulled up with 5 Volt which runs in the same cat5 cable. I do not use this 5 volt to feed the arduino it only does pull up. If you try this yourself it’s fine, but a big caution must be added, your Pi must be a master on the I2C bus, and must stay that way!. I must say. it is stable as hell (ok only one device is added to the bus). I take measurements every minute of the temperature and light intensity. The next change is to do logic level conversion and use I2C extenders and isolate it. I want to have an I2C ring in my home. The software on the Atmega is written by marcel though, and he is uding it also to control his adafruit led strip with the server.
Here a photo of the software running on the (second) raspberry pi. It shows the 3 devices currently active on the server.
The I2C test speaks for itself. It is the I2C device in the previous photo, it shows the temperature next to the device, and the graph is being plotted by the I2C data (datatype=”double:LUX”) tag in the device xml on the server. The unknown caption on the button says it does not know the power state (because i do not check this currently), and has a shortcut button to show a popup where you can select the color for the attached led strip (implemented for Marcel).
It also shows two light devices (where i put one light device in a different “Unknown” category on purpose). These devices are based on the SELECTREMOTE device which only can toggle between on and off.
It has two icons in the top left which shows there is a data connection and the client is logged in (when the server goes out for some reason, the client simply waits for the server to com back up).
It shows the current time and day of the week, with the system state next to it.
It also shows the login name on the top center.
Every device also has it’s own main control screen, just tap on the device name to pop it up, but this can be seen on the client’s screenshot page.
Well, this was a long posting to tell you guys about some progress i’ve maid with the server and the client. Marcel is also quite busy with a lot of stuff, like the I2C for on the arduino, creating some base devices and even a complete system to create audio segments in his house.
I hope it has been a little fun reading.