Open Source Home Automation (Raspberry)
-
@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.
-
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@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...
z-wave - Vera -> Domoticz
rfx - Domoticz <- MyDomoAtHome <- Imperihome
mysensors -> mysensors-gw -> Domoticz -
@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...
@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 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.
@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 ...
-
@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...
@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 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.
@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 ;-)
-
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/My Domotica project: http://www.pidome.org
-
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/ -
@John-Sirach
:thumbsup:
Nice project you got going! Let me know if you need help interpreting the protocol while developing the MySensors plugin.
@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?
-
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.
