Open Source Home Automation (Raspberry)
-
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 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?
@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 -
-
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.
@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-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 -
@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.
-
@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.
-
@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.
@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...Fulltime Servoy Developer
Parttime Moderator MySensors boardI use Domoticz as controller for Z-Wave and MySensors (previously Indigo and OpenHAB).
I have a FABtotum to print cases. -
@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...@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..
-
@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 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?
@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. -
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. -
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.@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. -
@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:
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.
-
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!)
-
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.
-
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/My Domotica project: http://www.pidome.org
-
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/@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 ;-)
-
@bjornhallberg
Disable the ssl in config/system.default.properties or copy and paste the below line in config.properties (default has precedence)server.enablessl = falseAnd 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.
-
@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
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?
- 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.
-
@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@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.
