This page last changed on Feb 07, 2014 by mixedup.
So I basically want to:
a) in first instance extend the platform to monitor a feed of solar data & trigger remote switches based on logic (see below)
b) perform it via extending an existing home automation piece of software that:
- supports for X-wave, X10 etc out of the box
- support monitoring over internet (browser based - i expose my webserver via port forwarding - does not have )
- ideally would be open-source (but otherwise highly extensible closed source)
- extensibility mechanism would need to have flexibility of some language support (if/then, etc)
Specific initial requirement details:
a) Receive a feed of input data from power consumption/solar generation:
b) Process this data: My code (where I extend the platform) would review every few minutes and make decisions re switches devices on/off
c) Trigger remote Power Switches (Z-wave)
Your question is rather generic, but on that level I would say things you want to do, can be done within OpenRemote
- ad a) At first glance I would say the Netsmart device might be used for collecting energy data. But you have to see if it is fit for reading with our Http protocol.
- ad b) Can be done with the built-in Drools engine. Definitely if you are familiar with Java a lot can be done there.
- as c) There is native support for Z-Wave switches and dimmers.
I done a piece of Solar production monitoring (http://www.openremote.org/x/TyVdAQ)
Further reading OpenRemote 2.0 User Tutorial
Posted by pz1 at Feb 07, 2014 07:54
thanks Pieter - so I'll need to read up in the User doco then how flexible the Drools engine is I guess, to see how flexibly it can read in realtime data...
Posted by mixedup at Feb 07, 2014 10:23
Looked a bit into the Netsmart. It appears to be not that smart. It only reports every so many minutes to the Website of the company where you bought it. So it will only be useful as long as they happen to conduct this business. I would always choose to be in control of my own primary data.
So it also seems unlikely that you can read directly from the device using the http OpenRemote control. But you can always ask the supplier if there is a backdoor....
Posted by pz1 at Feb 07, 2014 12:21
might be easier even to keep what I'm trying to do a separate program on the device, but still have open remote running there separately perhaps...
Posted by mixedup at Feb 08, 2014 09:13
that is an option. Quite a few people do use shell scripts to make a link. (see e.g. this)
Posted by pz1 at Feb 08, 2014 13:37
Thanks Pieter - actually on the Vera forums someone pointed out a constraint for the DIY Zwave'r. Would be interested in your comments?
You still can't use Z-Wave Locks with any of the open source Z-Wave projects.
The Secure Z-Wave protocols are locked up with NDAs and very expensive development kits.
This was a non starter for me.
Ad a developer, there is a huge difference in the level of abstraction at the Z-Wave protocol level (provided by Z-Wave devices) compared with what you do using Vera.
The comparison is kind of like the differences in programming for Socket vs Ajax Requests.
Posted by mixedup at Feb 08, 2014 19:42
I don't have a Vera, so I can't tell. I do have a RaZberry, which gives a pretty low level approach to the Zwave devices. At this moment they haven't implemented all standard command classes yet. As a result some devices are only partially supported. Their inteface does allow to determine which commands are available for a specific device. You have to do quite a bit of reading to understand. At least I had to. The RaZberry approach breaks, in case individual suppliers have made implementations that do not communicate correctly with their competitors. These incompatibilities seem to be partially due to weak specifications.
Other controller suppliers seem to take a device oriented approch, where they have the option to make a "kludge" around a deviating device. (For which the consumer has to pay...). But the RaZberry has plenty of problems too.
I have noticed that some companies have only part of their devices certified. As one of the key features of Z-Wave is a meaningfull interoperability of devices, it is a major flaw that the Z-Wave alliance does not publish a centralised open register of certified devices.
I wouldn't be surprised if Z-Wave, despite of good technology, is only a minor player in five years time.
Posted by pz1 at Feb 09, 2014 10:16