Xeoma - yet another option for camera management at home

I've been looking for new camera software and the recent test was done with xeoma which isn't open source softwar,e but it also is not that expensive compared to many other solutions especially when you want to have your recorder something that you can easily upgrade and maybe even have it done something else as well than just surveillance monitoring. Usually though surveillance monitoring is so heavy that device that records doesn't do much more than just record.

Xeoma has webpages at http://felenasoft.com/xeoma/en/ where one can find all the needed information and download the software itself. Xeoma works on Windows, Linux, Max OS and even on Android. For my personal use Linux is the one that is most important, however I don't exclude windows really as it would be good for remote access possibilities. Why? Because the cameras will not be monitored by me but e.g. my parents who are quite tight to Windows world. :) The version used in this quick review was 14.7.18 64-bit for both Linux and Windows also should be noted that I used the Trial period version during this initial review.

First startup

First time I started xeoma for testing, it was very nice surprise to see that Xeoma could find local webcam and also my IP cameras (on Windows) that were on same IP subnet with the computer I started the application with. It didn't however find automatically the cameras that were on my other subnet in my local network, but that is understandable. The cameras that were found automatically were running default settings and did not have restricted access, which probably helped quite a bit. This initial device search made it very easy to check the configurations and start testing some of the features especially as for me it showed more than one camera. Here is a sample photo with some cameras showing in the xeoma monitoring screen.

I must admit that the User interface feels a bit confusing at first and there are some problems with it as well, but once you get used to it it is usable. For example I could not use "tab key" on keyboard from going from one field to another which I have used to do a lot, but that is not a blocker just a minor annoyance. Also when typing the camera settings when typing faster the info row was not updating properly. Anyway these are just something that you have to handle only when you setup the cameras. After you have setup everything and have all the recording and cameras etc. done properly there is not really anything to do anymore and then the simplicity of the UI kicks in when monitoring the cameras.

By default the cameras added to Xeoma have very simple default module chain that has the actual camera, scheduling, motion detect and previewing and archive modules enabled. This is quite nice combination for many, however for my use I removed the schedule as the first things what I did just to make the chain simpler and because I want to have cameras always on recording mode.

For my use motion detection is the main thing that I need which has been made quite easy in xeoma. Also the default chain contains automatically the motion detection as said above, so it was easy to configure from the start.

Connecting to remote Xeoma server

Also after starting up the xeoma on Linux and checking the password with following command

./xeoma.app -showpassword

I started xeoma on Windows machine, entered the details of my linux machine and there it was instantly viewing of the content from my Linux machine on Windows machine, so simple! Almost love at the first sight ;) On Xeoma client application side to go through following flow "Main Menu >  Remote access > Connect to" and there entered IP address kept the port the same 8090 and added the password from the Linux command line. Of course this assumes that you dont have firewalls or have made rules for the 8090 port on the Linux machine.

Impressions

So far Xeoma looks very promising, but I have to do longer term tests to find out if it suites for all of my needs or not. One thing that I noted was that the memory usage of xeoma is reasonable and it does not take too much memory by default at least in this kind of sort time testing. If this is the final solution for my environment is something that only time will tell :)

Looking for video survaillance solution

I have been looking for a while for good solution for surveillance software and it has been quite hard without putting lots of money into it. First try was using the build in solutions of the cameras, i.e., FTP uploading. This was proven quite hard as it introduces a lot of points for errors. Each camera had to be controlled separately for settings from the webui pages. The most issues were caused by the old D-Link DNS-323 nas running 2x500G harddrives. The NAS was chosen over E-mail uploads as the e-mail uploads need constant network connection as well as lots of bandwidth if one extends the cameras up to 8 that is the current plan. Also because some of the cameras will watch home yards which have lots of trees and bushes that move in the wind, it makes quite a lot of traffic which is not really suitable for e-mails.

After all the problems with the solution above I started to look for NAS solutions that have surveillance features such as QNAP or Synology, the cost on those would be quite high as the hardware itself costs hundreds of € and then the license another X€. This would also mean that one would be on tight to that hardware and new requirements in the future would mean buying completely new hardware without possibility to really just do e.g. cpu or memory upgrades. Similar problem would be also with devices like dahua NVR's which have limited hw specs and in the end as the plan is to try different type of cameras buying NVR from one brand could limit the cameras that can be attached.  So the plan changed to have dedicated computer to run on these.

After the decision about dedicated computer I found out about iSpy that have been using for a while. iSpy is quite nice solution and one of the best thing is that it is free and open source (excluding some special services). After using it for couple of months it still feels that it is not the best and seems to be a bit too complex for and hard to use. After some time one of my friends pointed out xeoma which seems like an interesting option, which I will test next.


Currently I have 3 cameras in the network, Dahua IPC-HFW3200SP PoE, 2Mpix Full HD camera, Foscam FI8918W VGA WiFi camera and then one unbranded 2Mpix PoE bullet camera. More cameras will come later when I get the base of the system done and running. Only one of the cameras is currently in the final position at the moment with proper cables etc.

Nemo Mobile on CuBox

Finally all the needed stuff for cubox have been merged to Nemo and Mer and I got time to cleanup the adaptation bits a bit as well. So now we have Nemo Mobile running on CuBox, there are some bits and pieces still missing but it can be already used to some extend. Main issue seems to be with the graphics drivers, but anyway here is a short video of it..

Creating your own image

To create an image you need to install Mer SDK and then login to the sdk as guided. Download the .ks file

curl -O  http://sage.kapsi.fi/sagestechblog/cubox/cubox-2012-10-16-armv7hl.ks

And start the image build:

PATH=$PATH:/sbin sudo mic cr raw cubox-2012-10-16-armv7hl.ks --arch=armv7hl

Next thing is to put the image to the microsd card, example guide in nemo wiki. After this is done put the microsd card to the device and that is it.

Nemo Mobile UI on Snowball

I have been working a bit again with the snowball and now I got the Nemo Mobile UI booted on the device. It is still missing some bits and pieces but it is already something that can be easily tested and reproduced.

Here is a quick tutorial how to make an image yourself. First you need to get the Mer Platform SDK to build the images to which there is quite nice installation guide in the Mer wiki pages.

After you have installed the Mer Platform SDK log in and download the .ks file for building the image.

curl -O http://sage.kapsi.fi/sagestechblog/snowball/snowball-2012-10-16-armv7hl.ks

After getting the .ks file you need to modify it a bit, and instructions for that are in the .ks file so you need to do some reading ;).

When .ks file is modified you can build the image with following command:

PATH=$PATH:/sbin sudo mic cr raw snowball-2012-10-16-armv7hl.ks --arch=armv7hl

After image is built you can put the image to microsd card by following for example Mer wiki.

Now you are set for booting the device, have fun. Here is a very short video about the performance.

Booting Mer on CuBox

So here it is CuBox very small and quite nice piece of hardware made by SolidRun. It includes for example HDMI, 2x USB, 1x eSATA, build in console with microUSB and best of all it is packaged to very nice and small casing. By default Cubox developer platform comes with sd card that has ubuntu installation on it, but when I got the device I had already decided to try to run Mer on the device.

After some time I got the device booted and posted a message in the twitter about that as well and promised an blog post about how everyone else can do the same thing as well, so here it is.

Booting Mer on cubox is relatively easy, what you need to do is to get the image (.raw.bz2 file) I made from http://sage.kapsi.fi/Mer/CuBox/20120801/ and use dd to write the image to the sd card. Guide to image writing can be found from  http://wiki.merproject.com/wiki/Nemo/Installing#Raw_Image_Write

After the image is written to the sdcard enter the sdcard to your CuBox and power it on. Currently the image has a bit limited functionality, however the following features I tested:
- Serial with microUSB
- Ethernet via RJ45 connector
- HDMI with normal fbdev driver without any hardware acceleration
- USB ports ;)

I bet many other features work as well, but for now those were the most interesting ones for me to get the device booting and to network. The image that is available on the URL above boots to full screen xterm.

I will continue working on CuBox in near future and try to get the 3D driver working on it. If you are interested of helping to get this done feel free to come to chat with me to Freenode IRC network on channels #mer and #nemomobile.

Setting up qt-components "devel environment"

I have been fighting myself a lot about how to start learning QML and contributing to QML/qt-components based application in Nemo Mobile. I tried to use qt-creator some time ago, but that didn't work out as I would have liked it to (read was not so simple that I would have though, as Nemo isn't official target). After discussing with some of the community developers decided to try out to just compile applications manually on my desktop env and then run apps on there and try what my modifications did and later package for the real environment. So here is what I finally did..

First I needed to install qt-development tools for the linux distribution I have currently installed, i.e., openSUSE 12.1. So I needed to install libqt4-devel package:

sudo zypper install libqt4-devel

Then it was time to get the qt-components, which can be found from gitorious. So get them from there and install:

git clone git://gitorious.org/qt-components/qt-components.git
cd qt-components
./configure -meego
make
sudo make install
cd ..

Then it was time to get themes working for the qt-components. For this I installed first the base theme called meegotouch-theme:

git clone git://gitorious.org/meegotouch/meegotouch-theme.git
cd meegotouch-theme
qmake
sudo make install
cd ..

And then I installed the actual theme. For this I used the default theme that is provided also in Nemo Mobile called meego-handset-theme-darko:

git clone https://github.com/jpavelek/meego-handset-theme-darko.git
cd meego-handset-theme-darko
sudo mkdir /usr/share/themes/darko
sudo cp -r meegotouch/ index.theme /usr/share/themes/darko/
sudo cp -r blanco/ /usr/share/themes/
# Blanco has links to meegotouch which we add from darko theme
sudo ln -s darko/meegotouch /usr/share/themes/meegotouch
cd ..

And finally I took one of the qt-components/qml based applications that is in Nemo to try out my configuration

git clone https://github.com/nemomobile/qmlfilemuncher.git
cd qmlfilemuncher
qmake
make
./qmlfilemuncher

After this I had the QML/qt-components application running without any problems. So time to start learning more QML, fixing bugs and implementing features. :) Of course this doesn't include yet all the libraries and API's use in Nemo Mobile, but it is a start.

Tizen Developer Conference Day 3

Similar to the day 2 the third day started with a breakfast at the Atrium level and was in my opinion very good as well. After the breakfast I headed to the street level to get the giweaway present, i.e., Tizen Developer Device that was presented yesterday during the keynote given by the two Tizen TSG members Imad and Jong-Deok.

After getting the device it was of course time to check the content which was pretty basics, the device itself, micro usb cable, charger, which was surprisingly with a euro plug instead of US plug and a converter from euro plug to US wall socket. Also a cleaning "thingy" and 4G USB memory stick with SDK files inside were provided.

After unpacking and booting and testing the device a bit I headed towards the talk rooms to get some more information about the happenings around Tizen.

First talk of the day that I went to listen was "Developer Highlight Presentations: HTML5 Apps Development for Tizen Devices" which was a bit hard to follow probably mainly as the jetlag still prevented me from sleeping enough and I still wasn't awake really. :P

Next went to listen "HTML5 Canvas vs CSS3" presentation which was quite interesting and after the presentation listener had a better understanding about the differences. Also I was interested about the demos shown and how capable CSS3 actually is.

And of course one needs to eat as well, so went for a lunch in the Atrium level a bit after noon. Food was good as usual.

As a last talk I went to listen "Enabling Gordova (aka PhoneGap)" talk by Rene Pourtier.

The final part of the event for me was the Tizen SDK Hands-on session which was very nice session and gave very detailed and quick introduction to the different features of the SDK. The session consisted of three different parts, first part was how to use the SDK itself and how to get started of creating application with a template and how to run the applciation in the emulator. Second part was about how to use the debug functions within the SDK.

 
And the last part was a QA session with the SDK development team. There were many questions from the community about the SDK. However, there was one thing that bothered me and that was one person who kept "asking questions" and talking about many other things also than the Tizen SDK. Much good time from others was wasted with this non SDK related talker.

That was it, the conference is over. I had a lot of fun and got reasonable amount of information about the current status of Tizen and how to start hacking. It was also very nice to see the community and connect to others that are working with similar things. So thanks to Linux Foundation, Intel, Samsung and other sponsors that made this event a success.