Open Source Home Automation (Raspberry)

[Anticimex]

@bjornhallberg
I am running Domoticz on my rPi and I think it runs well. I have only added my 1-wire temp and light sensors currently (light sensors not working very well, but that is not Domotcz fault). I have also plugged a Tellstick to the rPi and managed to get it working as well, so I am going to stick with Domoticz for now on the rPi.
I have a Vera as well, which I plan to use to make sure my sensor nodes work as intended (since Vera is "officially" supported). But for "the future", the rPi is to me more interesting, and can be extended with zWave support as well. So I would love to see MySensors support on Domoticz eventually.

I have a pathological hatred for anything Java related, and especially on resource-limited devices so any HA solution based on that is ruled out by me. I tried openHab but could not get it to work properly, and it was s.l.o.w.

[axillent]

@Anticimex I will prefer to not limit smart home by RPI
RPI is good to be a bridge between mysensors network and smart home controller
and also a bridge from mysensors devices to mysensors cloud

but smart home controller is something else
I have vera running for 4 years
vera3 is much more powerful comparing to RPI but still there is lack of performance and resources

may be RPI can handle 5-10 devices but if you intend to automate more the RPI will became a bottleneck

I will be looking for nettop PC based computers running UNIX or windows

[Anticimex]

@axillent A PC based solution is probably the best from a performance point of view.
However, I currently has absolutely no sensors interfaced to my VeraLite and 7 temp and 7 light sensors connected by 1-Wire (and the tellstick) on my rPi, and my rPi totally wips the ass of Vera when it comes to performance and responsiveness. It all depends on the back-end and how fancy the frontend needs to be.
But when in doubt, use PC. That is by far the most flexible option.

But to not hijack the topic too much, the question here is limited to SW that works well on rPi

[bjornhallberg]

@axillent Sure, a more powerful solution wouldn't go amiss, but it comes down to cost and power consumption. The RPi SHOULD be enough to power home automation if it was was done right. A lot of the resource consumption for Domoticz (which is still a lot faster than openhab but is nevertheless accused of being slow sometimes) seems to be Apache handling the web interface. Lighttpd might be something I should look into if at all possible. Personally I'd like a really light-weight front-end and then some Android app to control and check the automation server.

But I'm always open to suggestions. The RPi is only great because of its software support / developers, its peripherals and its gpu. There should be a lot faster chips these days, ARM or preferably x86, that could manage the same power consumption as the Pi but with a lot better performance. If you're only looking for CPU cycles. Personally I was hell bent on cramming as much stuff as possible into the Pi, including the camera module. That is basically £6 of electricity, running it 24/7 for a year. Yes, I'm the ultimate cheapskate

[Anticimex]

@bjornhallberg I installed Domoticz on my Pi using an image, and it seem to run nginx, and not Apache. So far, I have not experienced any particular lag. Fingers crossed...

[BSoft]

I think the intent of rPI as a mysensor controller is an easy open customizable/semi-universal database service delivery to cloud, and in that department there is no reason to consider it as a bottleneck. And as a mysensor network controller should not be a problem also, i mean, controlling nodes does not require an horsepower machine.

[jendrush]

@Anticimex said:

I have a pathological hatred for anything Java related, and especially on resource-limited devices so any HA solution based on that is ruled out by me. I tried openHab but could not get it to work properly, and it was s.l.o.w.

I can confirm that. I've tried OpenHub Demo, and it was very slow on RPi. Idea for OpenHUB is nice, but Java kills this idea on slower machines.

[Yveaux]

Anyone familiar with MQTT (Mqtt.org)? This is not a home automation system but functions as middleware that stores data. Clients can subscribe to topics or publish topics.
Topics are ordered in a directory-like structure, e.g /mysensors/node123/sensor6/temperature.

I built a simple software gateway that routes sensor readings from a mysensors network to an MQTT broker, and routes actuator values from a MQTT broker back to the mysensors nodes.

Powerful rules can be created easily, like subscribe to a light sensor and a motion sensor and publish a light-switch-on when it is dark and motion is detected.

It might sound complex, but in reality is quite simple, super lightweight (runs easy peasy on RPI, see mosquito.org) and very scalable (brokers can be publish/subscribe to other brokers).

Only thing I still need is some UI to manually control sensors/actuators and edit rules

[mikeones]

I have been using agocontrol on my RPI with pretty good results. The few issues I posted about in the agocontrol form are likely user error on my part. I think ago is written in C and runs well on my PI. I am currently running 4 nodes with about 22 child devices. They have implemented just about all the device types which is a plus. I am running temperature, humidity and distance sensors along with relays and reed switches. Communication and stability have been solid so far.

I recommend agocontrol to anyone wanting to get some sensor nodes up and talking to a control that don't have a vera. They have x86 packages also so you are not limited to only running on a PI.

[bjornhallberg]

@mikeones I managed to get agocontrol installed and running after much grief. Can't really make heads or tails of the interface yet, and I get mysensors errors ("mysensorscontroller is not responding. Unable to execute action.") when going to the mysensors configuration. I did apt-get the agocontrol-mysensor package and it seems to start perfectly. Perhaps it has to do with the beta gateway code. Do you need to configure the serial port in the settings? Because I can't seem to save any changes made? /dev/ttyACM0 doesn't normally work when opening a serial monitor for me. I need to use /dev/ttyUSB0.

Overall I'm not sure agocontrol looks like my cup of tea. Seems the scope is just too ambitious and not as streamlined and user friendly as it could be. It is however pretty snappy (at least with no sensors configured). I'd still put my money on Domoticz.

• edited the list above to denote applications that have difficult requirements or requirements that may impede performance (Java ...).

[Yveaux]

@bjornhallberg are you running the 1.4 code on the gateway & sensors? The serial protocol has changed with 1.4 which could cause the issue...

[Damme]

I tried Agocontrol my self and don't really like it..
maybe its time for a new project "Yet Another Home Automation System" ... =(

Edit;
Any of the one's listed someone like? Me myself will be running the server on a linux-server so RPi is not really necessary.. I've been looking through them all now and didnt really fall for any of them.
Android-client would be good too

[mikeones]

@bjornhallberg Did you add the mysensors config file?

$ cat /etc/opt/agocontrol/conf.d/mysensors.conf 
[mysensors]
device=/dev/ttyUSB0

[bjornhallberg]

@mikeones said:

@bjornhallberg Did you add the mysensors config file?

$ cat /etc/opt/agocontrol/conf.d/mysensors.conf 
[mysensors]
device=/dev/ttyUSB0

That seems to have done it, thanks! I wonder why the webui/ago couldn't create that file itself.

[Damme]

I cant decide which software I want to run. I dont really like any of them
I was thinking about openhab and use the ethernet + arduino and make a new gateway software for openhab. (openhab can utilize UDP)

But I think openhab is a bit complex in the configuration. Or me just stupid..

[hek]

@Damme
I don't think you are stupid. Many of these HA systems is over complex and a bit too hard to get up running for normal people.

[bjornhallberg]

@Damme Yeah, that is sort of the Achilles' heel of the MySensors project. Basically no software support. And even if all the above software miraculously started to support MySensors, they'd still be years from completion most likely. I can't claim to have tried them all but none of them seem that promising. Most of them are half-baked and those that show some promise are usually developing too slowly or are under the wrong direction focusing on the wrong things or getting ahead of themselves. A lot of them support various wonky commercial hardware that ordinary people will be less likely to have heard of than MySensors even. Some of them sure have the cart before the horse and I'm always a bit suspicious about where their motivations are coming from, i.e. any money trail to said obscure corporate stuff that most people are very unlikely to own.

If I had any use for Z-Wave I might have considered getting a Vera, but for that price you could get pretty much anything, like a NUC or whatever (some of them are quite energy efficient and getting better every generation). Not that an x86 machine would me much use either compared to a RPi. And besides, all I hear about the Vera is complaints about slow software development. I'd expect more UX perfection from a commercial product. Perhaps I will reconsider if there is a Vera4 or something and UI7 is a resounding success. Else, people might do what they did to Synology, rip their software and let everyone use on their own hardware.

Isn't Google coming out with something soon? Or are they busy with the expensive NEST stuff?

[Damme]

@bjornhallberg Agree, I just looked at 'The thing system' but I cant even get the freakin thing to work (never used nodejs before...) but they do have a well documented tcp protocol ( http://thethingsystem.com/dev/Simple-Thing-Protocol.html ) and there are even some arduino examples too ( http://thethingsystem.com/dev/Thing-Sensor-Reporting-Protocol.html ). But it seams to be a bit much work to get it compatible with mysensors (and I dont even know if I like TTS yet.. )

[bjornhallberg]

@Damme TTS caught my eye the first time around, but I sort of dismissed it because it was node.js, immature, unheard of, and seemed reluctant to show much of its web gui. Seemed more like a concept and a bunch of techno babble. Also, support for a bunch of expensive commercial stuff that I'll never buy (Tesla cars anyone?). And, no smartphone apps (yet). I guess they're the sort of hipsters that like to run things in their smartphone browsers. But I can see the potential here. The web ui seems pretty snappy from their vimeo demo, and like you say, they have basically served up a functioning example of how to interface with an Arduino.

They sort of shut me up about user interfaces also. Their web ui is so different it seems to be from the future
http://vimeo.com/88873020#t=240

[toni]

@Yveaux openHAB has binding for MQTT and it has GUI (html5 and mobile app).
https://github.com/openhab/openhab/wiki/MQTT-Binding
https://github.com/cdjackson/HABmin
GreenT UI Demo – 01:19
— Mihail Panayotov

[Yveaux]

@toni Yeah, I also figured that out already, but I read some negative things here regarding openhab. Do you have some experience with it?

[toni]

I have a little experience with it. I have it installed and running on a virtual machine. So far only sonos and xbmc binding started. Which works fine. Will add ZWave and rfxcom as soon as I get the time.
Learning threshold is a bit high at beginning but once you got the hang of it, it feels really smooth and you have full control. Im migrating from ver lite.

[bjornhallberg]

Those that did try openHAB (and felt it was slow), what version of java did you use? Did changing versions make any difference?

I see that they recommend a very aggressive memory split also, leaving nothing for the GPU on the RPi. That is obviously impossible for those of us that also run the camera module.

Edit: Perhaps someone would be daring enough to try openHAB 2.0 if and when it works:
http://kaikreuzer.blogspot.com/2014/06/openhab-20-and-eclipse-smarthome.html
Includes HABmin, and ...

A second major design goal of openHAB 2.x is the optimization for embedded platforms. Although openHAB 1.x works on a Raspberry Pi, it sometimes feels a bit sluggish at startup or with huge installations - this is due to the fact that openHAB had never been specifically optimized for embedded systems and thus uses libraries such as Xtext, which are not meant to be used in constrained environments. In consequence, we will try to provide a minimal openHAB runtime that will work with alternatives or strategies such as pre-compilation etc.

[Damme]

Maybe I'll leave the topic a bit, because I don't use raspberry myself but a linux server for my 'brain' so I don't have any problem with 'slowness'.
I tried out openhab and actually likes it now, it is a bit ass to start up the configuration but then you learn it you'll easy put in new stuff. I might do a tutorial later on..

But right now I'm looking at the communication between mysensors and openhab and yes I know there is one script written but I was thinking of making a new gateway software for the arduino.
using mqtt protocol that is supported in openhab, and has a arduino library http://knolleary.net/arduino-client-for-mqtt/ ( https://github.com/knolleary/pubsubclient )

an alternative to mqtt is to write something completely new using tcp binding or so, but I think its inventing the wheel all over again.

[Yveaux]

@Damme I use a standard Ethernet gateway for mysensors and convert the mysensors messages using a quite simple Perl script running on my server (also not using RPI, so who cares about performance ).
This script automatically publishes and subscribes to the mosquito MQTT broker, also running on the server. Works quite well!

[Damme]

@Yveaux do you want to share? I am still waiting for my ethernet sheild so I cant do much programming there yet but would be fun to try out the mqtt protocol..

[Yveaux]

@Damme Ok, take a look at https://github.com/Yveaux/MySensors_MQTTGateway
No documentation or getting started yet, no time Sorry...

[hek]

@Yveaux

Nice. Forked it from MySensors-github so people will find it easier.

[Yveaux]

@hek Thanks! But I really need to start on my blog to document all the stuff I do... I'm afraid it isn't really self-documentary...

[Damme]

@Yveaux I made it work but with lots of changes, first I use serial and not ethernet on the arduino, and then I didnt find the AnyEvent::MQTT, I use Net:MQTT instead. So basically its not much left of your original script, but it was just for testing MQTT a bit.

I think it would direcly in arduino..

[epierre]

@Yveaux I have the classic one : https://github.com/empierre/domoticz?files=1

but since you're perling I can contribute... and maybe add/create the imperihome rest intetface on top... but You'll have to overcome some isdues related to the absence of UI

[Yveaux]

@epierre I'm afraid I don't get you...
So you're on domoticz, and you already have a gateway to mysensors?
Why do you want to switch to MQTT then?

[epierre]

@Yveaux no I mean to make a mysensors gateway to imperihomr

[Yveaux]

@epierre You could use my code as a start to connect to a mysensors Ethernet gateway and read/send messages, but it is really meant to bridge to MQTT protocol, and you don't need that, right?

[Yveaux]

@Damme I did start with an arduino implementation buy as MQTT is text-based I needed quite some flash to store all the strings to convert the mysensors variable names and stuff.
This filled up my atmega328 almost completely and I got tired of all the trickery required to stay within the 32kb. I just wanted to prove and test the cooperation of my sensors and MQTT.
Then I realized the MQTT broker had to run on a 'heavier' platform anyway and decided that also my gateway could -- I see no use to stuff everything into an arduino.

If you're interested I can share the arduino implementation, but I no longer see the use for it.

If your changes improved my implementation then please share them with us

[Damme]

@Yveaux My script is not better than yours, I kind of broke it..

I had a thought that the atmega328 isn't enough, one option is to have external flash but no program code can be stoored there. The 32kb is still very limiting.
I had a thought of atmega2560, there is one model with build in ethernet and some with external, total cost ~30USD. It has 256KB flash memory.
So, yes I would be interessed in yout arduino code.. I might be able to slim the program down..

[filoucaenais]

Hello
go Jeedom
the project progresses faster
and I motivated to make a plugin for MySensors
there will be more people motivate
faster plugin advance

[Yveaux]

@Damme My code does only implement a MQTT client, not the broker. But if you still want it, chat me your email and I'll send it to you.

[Damme]

@Yveaux Ah, I been writing a broker, just need a new Ethernet controller to continue, hope it will arrive tomorrow.

[epierre]

@filoucaenais so bad all the core features in the market are to be bought... and that only zway which is now dying is supported, not openzwave...

@bjornhallberg @Damme even domoticz guy are pushing people to use something better than raspberry... for a little more you have a cubieboard2 which has 1Go RAM and 2 cores @ 2011 bogomips... For z-wave OpenHab is still the best choice...

[bjornhallberg]

@epierre Yes there are a lot better options out there, but I'm not going to buy a new platform just so I can run JAVA Nothing in this price range is going to be fast enough for that I suspect. Faster, sure, but not fast as in virtually instantaneous.

I actually tried openhab2 branch on the RPi just a few minutes ago. Slow Sunday, I know. Don't know if it has been optimized yet as promised but it took about 4 minutes to start. And then it used up 25% of available RAM right out of the box, running the demo config. Would be interesting to see how fast it boots on a cubieboard2 or similar. Even if it could get it down to a minute it would be a minute too much imo. Perhaps it will run fine after it's been loaded, but those loading times were enough to deter me. I mean, in 4 minutes your house could get burgled several times over I just don't see what openhab has to offer that is worth all that.

The reason I got a RPi was the camera module. And the extremely wide support for the platform. I swore I would never touch an ARM platform again after my first Android phone and my Synology NAS but I guess the price (and camera) got the better of me. I also don't have any z-wave devices.

On a side note, I've ordered another Arduino Uno Ethernet Shield to complete the bridge to the MQTT broker. I will just have to find some automation software that will run fine on the Pi.

[epierre]

@bjornhallberg on my cubie (paid $50 with a box), I have imperihome gateway, mysensors gateway, jeedom, domoticz and openhab running... load: 0,6 more than 200 Mo ram available even with kernel cache...

remember that the pi has no FPU... BogoMIPS : 464.48 ...

[hek]

@epierre said:

even domoticz guy are pushing people to use something better than raspberry... for a little more you have a cubieboard2 which has 1Go RAM and 2 cores @ 2011 bogomips... For z-wave OpenHab is still the best choice...

Ok, ordered myself a cubieboard2 to have something to compare with the RPi.

[epierre]

@hek if you want to stay on a debian (as raspi), you can try from the SD this one: http://www.cubieforums.com/index.php/topic,1275.0.html

Kernel is quite new (not the official 3.4.75 but a 3.4.98 with temp sensor and watchdog), it is minimal so if you compile you'll add to add packages that are not present by default.

I moved because I aded dynamic linking to lua to acess sqlite3 from scripts, but it was reverted because of NAS users having compilation issues... compiling omoticz on raspi took more than 1 hour... on cubie a lot less !

Even better is the odroid, but it is yet another class (quad core, 4GB DDR3, Ekynos SoC of the samsung S3). More like an AMM counter

[John]

Hi I'm John and i'm developing PiDome together with a friend of mine.

The project is in an early stage and we just a couple of days ago are starting to support existing devices (Philips Hue was the first) and are going to include native MySensors support. When it will be included exactly i can not tell but it will be between now and some weeks. The main reason for this is that i'm doing the software and this friend of mine the hardware. So we are just two developers.

The project is aimed at the raspberry pi but being based on java, it will not prevent it will also run on other systems (windows services are in test fase for example). The project also exists of multiple sub projects. Like the server, Desktop OS like/small application and an Android app.
It supports websockets, raw sockets and webservice json-rpc entrypoint all these have secure and non secure ports, visual trigger editor (if this then that (else is on it's way)), floor planner (multiple floors).

It is an ambitious but in very early stage project with currently only quick follow up alpha releases and a lot, lot of testing. Maybe at some point it will be interesting when the MySensors support is built in and people are willing to test it.

[edit]
A little video about the project is posted here: http://pidome.wordpress.com/2014/05/28/pidome-explained-in-a-video-clip-with-web-interface-demo/

[hek]

@John-Sirach

Nice project you got going! Let me know if you need help interpreting the protocol while developing the MySensors plugin.

[John]

@hek Thnx! We're doing the best we can. If i have any questions i will drop you a line. When i take a look at the devices it's all fairly simple. The only thing i notice is that there are variable types, but no data types. Is this correct?

[daulagari]

Instead of every project reinventing the wheel I would hope we would come to a common MQTT gateway so at least part of the code to support MySensors can be reused and ... you can have multiple Domotica solutions in parallel working with MySensors.

Every Domotica project can then focus on how to handle the different devices the best but at least the interface talking to the MySensor network is standardized.

@Yveaux has already posted a script above not 100% sure how far this is off for a complete solution.

[hek]

@John-Sirach

Yes, that is correct. There are both device- and variable types. You can report multiple variables on one device.

When to use a specific variable type for a device is really a silent agreement between sensor and controller. Today you could actually report a temperature variable to a humidity device. It would not make any sense, but noting prohibits this. A good example where multiple variables is reported for one device is POWER-device where you usually report both KWH and WATT.

If we can find a more general way of handling this in the future (and not over complex from the sensors point of view) it would be good. We had an discussion going about this but the thread disappeared in an crash.

- I might split this into a new topic -

[John]

@daulagari One of the features of PiDome is the json-rpc api which is standardized for every device added. Every device is being reported in the same manner (data, structure, etc...). One of the features on our todo list is MQTT and not only for device communication, but next to the json-rpc api and to be used between multiple PiDome server instances. This would also of course make it possible to chain different type of domotica solutions. We are not yet done with defining the MQTT structure, but it will eventually certainly be done.

[John]

@hek Having multiple kind variables posted to a single device is no problem, it's more about the datatype handling because of possible automatic graph creations. It would be nice of there was a table somewhere telling what kind of data a variable is for the internal mappings used. But this would an other topic.

[daulagari]

@John-Sirach said:

It would be nice of there was a table somewhere telling what kind of data a variable is for the internal mappings used.

Yes, agree, and it would be even nicer if that table was in a machine readable format so that again not everybody has to reinvent the wheel.

[marceltrapman]

@John-Sirach said:

It would be nice of there was a table somewhere telling what kind of data a variable is for the internal mappings used. But this would an other topic.

You can start the yourself topic and publish the table
It is in the Vera files on Github...

[John]

@marceltrapman The internal mappings was meant for my project ;). When i take a look at the github code they all seem to be handled as strings? I meant in the case of a variable to be intepreted as a string,boolean,int,float,etc..

[daulagari]

@marceltrapman said:

You can start the yourself topic and publish the table
It is in the Vera files on Github...

I checked out the Vera repository and do not really see a table, what comes most close are the tDeviceTypes and the tVarTypes definitions in L_Arduino.lua.

Any better definition/source?

[marceltrapman]

@John-Sirach said:

I meant in the case of a variable to be intepreted as a string,boolean,int,float,etc..

@daulagari said:

I do not really see a table...

OK, now I understand

What I was trying to say is that many rely on @hek to do this work but we can contribute ourselves as well.
In case you think a table is what helps you to do the job it might be a good exercise to assemble that table yourself.
Apologies for not being more clear on that.

[hek]

The table is also represented here.
http://www.mysensors.org/build/sensor_api#the-serial-protocol

(an updated table will be created for 1.4 once we decide to make it official)

If your using the serial protocol to communicate with the sensor network everything coming to the controller is represented as a string. Some values might might have decimals where applicable like temperature. But this is really up to the sensor to decide.

Boolean values is represented by 1/0.
Some sensor values is represented with percentage 0-100 (e.g. DIMMER, LIGHT_LEVEL, BATTERY_LEVEL).
Yet is some values (or modes) is represented by a string (like for HEATER). But is uncommon and mostly a legacy from Vera.

[John]

@hek said:

If your using the serial protocol to communicate with the sensor network everything coming to the controller is represented as a string. Some values might might have decimals where applicable like temperature. But this is really up to the sensor to decide.

Ok, this is making things more clear, i will let the datatype the be decided by the user creating a device.
Thnx.

[sensorsusr]

@bjornhallberg
I'm currently using OpenHAB with a couple Arduino sensor nodes. It works great. It does everything you've put in your required list and then some: rules engine, slick android app and browser interface, email / push notifications, data collection and charts. The only missing piece is the GUI for scene creation, but it's in the works. Also, great active community.

Here's some videos and tutorial of what I've got working:

http://goo.gl/je6LzU

I was in the same boat as you. All these "Home Automation" platforms take a lot of digging into to find out where their shortcomings are, what they're capable of. Although I did not do an exhaustive survey of everything out there, I did look at a few on your list, and ended up with OpenHAB.

[Zeph]

See thread http://forum.mysensors.org/topic/248/generalizing-mysensors for some very related thoughts about making MySensors more easily and cleanly adaptable to different controllers, cloud storage, MQTT, radio networks, etc.

(For once, I had the self discipline to start another thread rather than embed that discussion in this related one, yay!)

[bjornhallberg]

Here are some benchmarks that also happen to include certain ARM platforms, like the Cubieboard, Raspberry as well as x86 Atom and NUC solutions. It also has the N40L Microserver that I run as a storage server (but am reluctant to run 24/7).

https://s1.hoffart.de/7zip-bench/
http://www.7-cpu.com/

Perhaps not entirely applicable to JAVA or node.js or whatever but nevertheless a good guide.

I bought my N40L for about €100 a while back (has since been deprecated by the N54L, don't know if it's still around?). Still stands up as pretty much the cheapest x86 board you can get, especially if you get the 4GB model and consider the performance which is better than a lot of fusion and atom platforms. Not super energy efficient though, even with the picoPSU mod and Dell powerbrick, and a bunch of 4TB drives obviously makes it even less so.

If this whole Raspberry thing doesn't work out I'd definitely look into Intel's NUC line-up. The newer i5 Haswell model (D54250WYK) can allegedly run as lean as 3.7-4.6W idle. I figure they might get pretty cheap once the next generation comes out.

[John]

I have put some support for mysensors in the software i'm using/creating. It is in early stage and there is some manual labor needed.
Still need to add:

• Automatic node addresses
• Automatic create node devices based on node presentations
• And other stuff that can be added, etc...

A penny for your thoughts:
http://pidome.wordpress.com/2014/08/10/added-partly-mysensors-org-wireless-devices-support-api-1-4-beta/

[bjornhallberg]

@John I did a quick install on my RPi to see how it would work out. I must say I'm impressed. Server web interface was up and running in under 40 seconds or so (openhab = 4 minutes). Very snappy and the interface seems like a good basis for a powerful controller. Shows real promise! Renewed faith in Java

[John]

@bjornhallberg
Disable the ssl in config/system.default.properties or copy and paste the below line in config.properties (default has precedence)

server.enablessl = false

And it will be even faster, it then disables the certificate generation(at least 5 seconds), ssl websocket, http and raw socket instances (couple seconds per instance type).

I'm glad you got it up and running quite quickly if i understood correct because the downloads are still in alpha state (snapshots). I wish i already had some example sensors in the DB so it could by tried out without having to create XML definition files yourself.

[Bandra]

@John
Your project looks great! I'm looking around for an home automation controller and was tossing between domoticz, openhab and FHEM.

My criteria are:

• MySensors support (whether directly or through a gateway)
• Z-Wave support
• Visual floor plan
• Runnable on a Pi

May have to add yours to the mix to trial.

How difficult would it be to compile openzwave and integrate it by some mechanism to PiDome, do you think?

[John]

@Bandra

• MySensors support: Almost completely done with todo's as including AUTO addressing and datatype assignments.
• Visual Floor plan: Available in the server and desktop client.
• Runnable on a Pi: This is the primary target.
• Z-Wave support: On our todo list: https://bitbucket.org/pidome/pidome-server/issue/70/add-zwave-support

OpenZWave is the best candidate to use but has not yet been completely looked into yet because the internal pidome device, web interface, and package management bindings api is not completely finished yet and grows with supporting protocols etc.. It is possible it takes between two and three months before it is included by default if i follow my roadmap.

MQTT is planned to be implemented after MySensors and other stuff, so if there is an MQTT interface for OpenZWave it should be possible somewhere in the end of September/begin October.

[Zeph]

@bjornhallberg said:

TTS caught my eye the first time around, but I sort of dismissed it because it was node.js, immature, unheard of, and seemed reluctant to show much of its web gui. Seemed more like a concept and a bunch of techno babble.

The spiel on The Thing System about having "magic" in place of user visible control raises my caution flags. It remind me of the frustrations that Microsoft's software sometimes generates - when what you want it to do matches what they expected you to want, it automagically just does it behind the scenes and you say "wow, cool" -- but when you step off the paved path and want to do something different, the branbles can become very complex and difficult if not impossible.

So if your water leak detector activates, the system should "just know" what the most appropriate actions are - without the user needing to specify or configure or any of that difficult stuff. But in many decades of dancing with computers, the software has never (in any complex system) done exactly what I want. I don't trust that there is one size that fits all when it comes to "automagically" doing what I want, that adapts to all varieties of systems and all preferences. I need the option (1) to clearly know what actions will be triggered by some event by default, and (2) to be able to override or customize that action.

The Ignite video "the Trouble with Things" linked from their site does not inspire confidence. They show a wireless keyboard television control and a three button remote control and suggest that the latter is much to be preferred. Yeah, I love using up/down/left/right screen keyboards for finding youtube videos, it's so much more intuitive than typing.

When I worked on dedicated word processor systems many years ago, we used to talk about the need for a DWIM button on the keyboard (Do What I Mean). But at least we knew that we were joking. I'm not sure TTS knows when they are blowing smoke in thinking they can design some kind of hidden smarts that magically and accurately does what the user means.

I am much more interested in user interfaces where the effort has been making complex things clear to understand and easy to control, than those that think they know what I need better than I do and want me not to worry my pretty little head about what they are going to do or how on my behalf.

(And I do get that their target market is not people who are willing to solder together and program their own wireless sensor network. They want to attract people who want home automation to be as easy as using a microwave oven or driving a go-kart. But I've seen misguided and arrogant implementations of DWIM frustrate and confuse non-technical users many, many times as well).

That said, they may come up with something worthwhile in some niches. But my warning flags are up.

[bjornhallberg]

@Zeph Yeah, it almost seems like a trend these last couple of years. I agree completely with what you say. I don't know how or why this came about, perhaps we are all experiencing the consequences of the Iphone boom and all that it ushered in. Windows 8, Windows Phone and even Android seem to be creeping towards this goal. A desire to reach out to tech illiterate people (and ultimately profit from them).

I just realized it's hard not to sound like a complete elitist though when talking about these things. Haha.

"Magic" wouldn't be so bad if it just didn't strip away user control and choice, dumbing things down, but it always seems to be the case. Like it is some ideological tenet. I can't shake the feeling that more often than not (in the case of Microsoft for instance) there are murkier reasons for doing what they do. Just like with the rise of "the cloud". takes off tinfoil hat

[A Former User]

A little late to the thread here, but as I'm constantly looking at open source automation software, thought I'd chip in.

My first forays into HA were with an RFXTRX and domotiga - it's a great system with plenty of interfaces. The downside for me was that it needs (maybe doesn't any more) a linux host to run the UI - I use a windows PC and the extra step of having to run a Linux VM to make any changes got in the way.... that said the vast number of options gave me a lot of ideas about what and how I want to automate things.

I spent around 18 months running AgoControl - I was impressed with this from the outset, and persevered for sometime with it's quirky interface (web gui isn't intuitive for building scenes and doesn't resize for tablet/mobiles). The deal breaker recently for me was one of reliability - I found the RPi needed to be rebooted every 4-5 days due to a memory leak issue with the AMPQ engine, a daily cron reboot of the RPi seemed to improve things, but then for some reason certain events wouldn't reload. I think (not sure) there were some issues with the openzwave wrapper which caused a few issues and slowness with the response times. The second issue I had was that the majority of the plugins are written in perl, which seemed to dramatically slow down the system when more than a couple were running.

I haven't given up on it - I still have an RPi set aside for AgoControl, and will look into it again when I have more time.

It was time to investigate issues which led me to purchase a veralite a couple of months ago, and while not in itself not quirky (multiple lua restarts needed to pick up changes etc), it has been faultlessly reliable in that two months.

I have looked at OpenHAB, it's vast number of interfaces (bindings?) and mature looking interface being the appeal. Unfortunately, despite being technically minded, I'm not a hardcore developer - and having looked at the documentation for OpenHAB, it looks hellishly complicated just to set up, let alone build scenes and so on for.

I've also played around with NodeRed and a few jeenodes and am considering/planning to use nodered and the mqtt gateway for mysensors to re-use some of the code I built to send sensor data to emoncms.org.

Cheers
James

[andriej]

Domoticz crew is looking for someone to implement (in C++) the MySensors api/gateway…
Here's the ticket if anyone is interested.

[bjornhallberg]

@jdr0berts Yes, it is unfortunate that both domoticz and agocontrol are such dinosaurs since they are the only ones doing C++. If PIDOME wasn't making such progress I'd probably have to give up on MySensors. At least mothball it for six months and see if something has changed. Sad truth of the day.

There are two things I wish I had realized from the beginning. One being how literally everyone is using a Vera (and z-wave devices as well) and is happy with that and secondly that the controller is responsible for more than just receiving and sending messages so mimicking the Vera is not entirely easy. Like the automatic nodeIDs? I had been a tad more skeptical as to the outcome had I known this. I'm not griping, I've just suddenly gotten a better understanding of what a 3rd party developer has to go through.

@andriej Slim chance of that happening. They're also looking for someone to write a C++ MQTT implementation. The current one is some sort of node.js to lua. With the lua missing. I've asked in their forums and at the guy's github about where to find the file. No reply. I understand the implementation was also quite slow so it might not matter. I.e. the antitheses of the quick C++ core.

@John Perhaps you could set up a dedicated PIDOME thread for some q&a and troubleshooting? It would probably also get PIDOME some more visibility for people ending up in the Raspberry forum looking for a solution.

[John]

@bjornhallberg
I think i've missed your mention. Yeah it would be a good idea, albeit not for exposure but for helping out if there are any issues with it (i already find my mailbox filling up with mysensors questions). So yeah i think it is handy to have a dedicated thread. But only if @hek agrees with having such a dedicated thread.

If PIDOME wasn't making such progress...

It still is going to slow (in my personal opinion).. especially with not having enough hardware to test with ;).

[hek]

I have created a "Controller" section and moved all relevant threads I've found.

@John
Please create a new PIDome thread here.

[bjornhallberg]

I stumbled upon HouseMon the other day ... anyone here try that? Seems pretty damn great, but a bit obscure and very hard (for me at least) to make heads or tails of. Uses a slew of catchy, modern tech (Dataflow, MQTT, LevelDB, WebSockets, AngularJS, CoffeeScript/Jade/Stylus, Go) all across the board and, most importantly, is quicker on the Raspberry than I would have ever imagined possible, including the web front-end. At least for the test setup. Probably because it uses a pre-compiled binary.

Installation:
http://aka-lightbulb.com/2014/04/28/housemon-0-9-x-on-linux-binary-installation/

Not exactly ready for public consumption yet but not so unlike OpenHAB in its design and complexity either.

[hek]

EasyIoT, Homeseer and Pimatic added to the list of supported controllers on the main site.

[hek]

MajorDoMo added to main site

http://www.mysensors.org/controller/majordomo

[GaryStofer]

@bjornhallberg I installed AGO and the Mysensor plugin on my RPI/b and after much head scratching and picking out little tidbits here and there on how to get this to load I have a MySensor sending data to it. -- The webgui is reasonably fast, but for the world I can't figure out what you actually can do with it or how you could use the GUI to configure any action to be taken depending on a Sensor reading. The Documentation is totally missing any hints as to how to use the thing.

Without any clue as to how to make this do anything useful I will format the Rpi's SD card again...

[bjornhallberg]

@GaryStofer Haven't used Ago Control in a long time. I wouldn't have recommended it in the past. Didn't like the AMQP deal. And there were other nuisances. However with version 1.0 coming up perhaps they have made enough improvements to warrant a new look. Support for the ImperiHome Android app is a big deal for instance since their own Android app was pretty basic. If you're not using 1.0 from their testing repository I can understand your frustration.

Personally I'm quite content with Domoticz for the time being. Easy to use and just works.

[Sean Brennan]

Hello I am new to all of this but I was so happy that this library worked out of the box. I went with MySensors and AgoControl and was elated until I saw that my servo would not move. It reported the distance sensor and switches worked, but "drapes" and "dimmer" did not. It was not difficult to find out how to add support and now my servos turn but I have not submitted code.
https://github.com/mce35/agocontrol/blob/master/devices/MySensors/agoMySensors.cpp#L732
Actually MySensors seems to have an enormous amount of supported types, and AgoControl seems to have a good amount but the glue, seriously probably the easiest part, is missing.

[GaryStofer]

@bjornhallberg I like to give Domoticz a try, but I can't find any mention of a MySensor plug-in anywhere in their Documentation nor on the Wiki. The only mentioning I see is on the MySensor.org controller page saying that it's supported.

How are your MySensors talking to it?

gary

[AWI]

@GaryStofer Take a look at topic, you need the Domoticz beta feed. The Domoticz Wiki pages are not updated for the MySensors implementation. @hek was there any new documentation?

[hek]

No, I haven't seen any new MySensors documentation on their wiki yet. Rob is on a business trip so I doubt there will be any the coming couple of weeks.

[GaryStofer]

@hek @AWI Ahhh beta feed! Yes, that helped. Now I need to figure out Why I get LUA / Blockly errors on all events. Something about a nil utilitidevice . Thanks !

[A Former User]

 It also has to be real AUTOMATION in the sense that you can build long and complicated scenes that can respond to changing condition in and around the house, preferably in some nice graphical interface where you just drag and drop the building blocks (Blockly).

The perfect solution to build such scenarios is to use Matlab/Simulink/Stateflow and model based design. In this way you can graphically develop control algorithms, state machines and simulate them in PC before you ever start testing them on real home. This is much faster, and it is also industry standard in automation, cars, avionics and space. Afterwards with just few clicks you can generate C code, which will run on any hardware. The code is totaly hardware independent - they have targets for Raspberry, Arduino, Lego Mindstorms etc.
The only problem - it costs some good money.
So finally all you need - is an automation software, which can execute C code.

[jkandasa]

@bjornhallberg @hek Can you add MyController.org in to Free / Open Source list as it is supporting for Raspberry PI?

MyController.org [JAVA] (SERIAL/ETHERNET/MQTT)

[m26872]

Why isn't ETHERNET listed with Fhem? I've been using eth-gw perfectly for two months now.

[bjornhallberg]

@m26872 Ok. Changed!

[John]

Hi @bjornhallberg,

We have been updating our website from wordpress to a self hosted platform on http://pidome.org, This means the url pidome.wordpress.com will be obsoleted and http://pidome.org is the new location.

Could you update the url?

Thanks in advance and cheers,
John.

[hek]

@bjornhallberg

Please add Calaos and openLuup to the list.

[John]

@bjornhallberg Thanks for the change!

P.S. i recently also added support for local /dev/tty* serial ports which weans that also the GPIO gateway solution is available (http://forum.mysensors.org/topic/2389/added-support-for-local-mysensors-rpi-direct-radio-connection). I know changes are a bit scattered but also is my implementation schedule, sorry ;).

Cheers!

[bjornhallberg]

@John @hek Done! Now also alphabetized. 100% less OCD

[Bluefox]

Include ioBroker. We support mySensors over MQTT protocol.
ioBroker has over 80 adapters/drivers and all of them developed with Javascript (node.js)

[TRS-80]

@bjornhallberg (+ others in this thread),

Interesting thread, great discussion about the pros and cons of various systems. I think we all go through these thoughts in our own heads at one point or another, some of us jumping in and trying different systems one after the other (which is sometimes the only way to REALLY know the system, as you correctly point out) and others (like me, and some others) prefer to read and read and plan a lot before jumping into something.

At any rate, the longer I keep evaluating different technology solutions (and this applies in general, could be anything from an email client, to a Home Automation solution) the more and more I keep going in the direction of evaluating a project more and more on their merits as an overall project, which largely is a function of who is leading the project and their stated goals, as well as the friendliness, talent, and numbers of the community that coalesces around that project. Also I think the lack of a profit motive (or at least, not so much of a greedy, overwhelming one) tends to end up benefiting the end user. I think all of these factors together will insure the ultimate success (or failure) of any given project (and most especially, how well it will end up benefiting THE END USER (i.e., you and I) )!

And so, after running into the various roadblocks (as have been described in this thread, which seem to usually be the results of financial interests of some company pushing proprietary, disparate systems, and/or the seeming trend of oversimplification of technology, as brought on by the introduction of the iPhone to the unwashed masses, etc...) I keep moving more and more in the direction of free and open source software. Which in and of itself is not enough. You also must have the good leadership, vision, and community as I mentioned above.

I find all of these criteria here in spades at MySensors, which is why I have decided to become a part of this wonderful, talented community!

Which brings me to my point. If you then go on and evaluate Controllers using the same criteria (and I have), I feel that OpenHab is the logical conclusion, and natural kindred spirit for a Controller for your MySensors network.

That is not to disparage any other communities or projects that anyone here is involved in. I think that, to a certain extent, and in a more general sense, that competing systems are good for everyone. However, in the Home Automation space, which I have been watching for a very very long time, there are TOO many different competing (and more importantly, non-interoperable) systems. What we have always needed is One System To Rule Them All (OK, perhaps rule is too strong a word, so instead let's say, allow for universal interoperability ). That way, the end users are free to pick and choose from all the various solutions available on the market, and know that they will have one system that will be able to tie everything together should they need to get something they really like from company A and make it work with some other thing from company B , or add some other functionality down the road, etc.

I have read a lot already, and I have more to read still, but it seems to me that (based on what I know right now) ultimately, OpenHab should be the project that those who feel as I do should throw their weight behind, and support into (hopefully) becoming that One System To Rule Them All (or Universal Glue, if you prefer).

This is just my 2 cents as someone who has been looking into Home Automation on and off for many many years and never fully took the plunge, as the stuff was too expensive and/or there were always a number of disparate, often proprietary, systems (that would not work together). I feel that all of the factors are coming together (inexpensive components, open source hardware and software, the maker movement and growing size of community) to finally allow the dream I think we have all had for a very long time to finally be fully realized. And I am very excited about that.

Sorry for such a long first post, I am just very excited to be here, and to see where we are at now and where we are going with inexpensive, open source Home Automation. And hopefully to eventually contribute something useful to the community, and in turn help the general state of DIY Home Automation move forward.

[hek]

@bjornhallberg

Please add the HoMiDoM controller. Supports MySensors through the serial interface.
http://www.homidom.com/driver-MySensors-c89.html

[Patrick Côté]

Home Assistant now support ethernet gateway

[jsiddall]

I just committed a controller module for Misterhouse if you want to update the list. Supports both serial and Ethernet gateways.

[hek]

@jsiddall

Thank you for creating a MySensors Misterhouse module!

[jsiddall]

@hek

Actually, now that I think about it, Misterhouse also has support for MQTT so you can probably list all three gateways for Misterhouse. Sorry for forgetting about that one in my initial post.

[hek]

The question is if it recognize MySensors topics and do things like hand out ids over MQTT.

[jsiddall]

@hek said:

The question is if it recognize MySensors topics and do things like hand out ids over MQTT.

Hmmm... good point. Hand out IDs, no, not out of the box, but set/req should work. For now I am fine to leave MQTT off and I will look at what would need to be done to add basic MYS specific internal support.