Securifi Community Forum
Securifi Products => Almond+ => Topic started by: rf134a on June 26, 2015, 03:33:35 am
-
Since Securifi is taking so long to add support for sensors, how about creating an interface similar to Vera? No one wants to install 100 v1 dimmers, then the manufacturer changes the led from green to blue and calls it a v2. Then, we're stuck waiting for a year for Securifi to add support for this "new" dimmer. A good example of this is the Aeon Tech whole home energy monitor.
Also, IKEA is supposed to be finalizing their own HA sensors. If these are on z-wave or zigbee, I'm sure we can crowd source the settings in days vs never from Securifi. I don't expect Securifi to buy 1 of every sensor on the market.
-
Whilst this sounds like a great idea I think it might be difficult to implement!
How do we know what settings / information we need to get?
How do we know we've got the correct settings?
Are we testing on our own devices? Flashing our own firmware? Creating our own firmware?
Lots more questions but I'll leave it at that.
I'd love to be able to crowd source sensor settings but I can't see how we could without significant work from Securifi.
-
Regarding the firmware question regarding device profiles.
Rather than having device profiles hidden away in firmware, we could have a private or public community repository, with updates, changes, customization, forks, control. Github is a nice option, Google just announced their own git repository hosting service. Lots of options for a growing number of sensors.
-
Regarding the firmware question regarding device profiles.
Rather than having device profiles hidden away in firmware, we could have a private or public community repository, with updates, changes, customization, forks, control. Github is a nice option, Google just announced their own git repository hosting service. Lots of options for a growing number of sensors.
I wouldn't call them hidden away in firmware.
It's a LINUX O/S and the xml files are easily located and modified.
If you are talking about github, you'd be working the same level of detail.
The same option is available to you now. The documentation is lacking to support an effort but is not difficult to create.
Log into your almond, goto the root directory, find . -name *.xml and have a look.
What we need is a process diagram used by Securifi. Which servers/software pieces look at which xml files and in which order and which log files are used by what.
-
OK so looking into this a bit it doesn't initially appear to be that difficult to do what we need to do.
For the ZWave sensors it looks like OpenZWave is being used. There's a wiki entry which could be useful.
https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices (https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices)
The command classes raises a question in my mind as I've not seen them configured (only referenced) in the DeviceList.xml files.
-
Can we get some information from the Securifi staff on whether we have the ability to add new sensor information ourselves?
-
Can we get some information from the Securifi staff on whether we have the ability to add new sensor information ourselves?
I believe the haserver software looks to /almond/config/ for the xml data/file to find a match for any sensor being added. If it finds a good match, it adds it accordingly and then the DeviceList.xml file is updated. If it does not determine there is a match, it can be added as an "unknown device". Not all the devices listed in /almond/config appear to be supported by haserver at this time.
The haserver can handle generic devices like Binary Switches but if you want something specific like the HEM1 profile from Aeon Labs, the haserver has to be coded to recognize and process that sensor, for exampling, polling intervals or what indices to track and report.
Short answer, you can probably add devices that utilize classes that are already supported, for example BASIC_COMMAND and BINARY_SWITCH keeping in mind that something like MultiLevelSwitch still has issues.
files to look at include /almond/config/options.xml options.xsd, zwcfg.xsd, zwscene.xsd,device_classes.xml, device_classes.xsd, device_configuration.xsd, manufacturer_specific.xml, manufacturer_specific.xsd
If you run a 'strings' command on /almond/zw_association you'll pretty much get the list of sensor that can be processed easily.
Thinking all of this should be posted in the Software Dev section?
-
we may not even need a HA Server anymore with AllJoyn on Windows 10, Android etc.
- https://allseenalliance.org/about (https://allseenalliance.org/about)
- https://msopentech.com/blog/2014/11/12/msopentech-alljoyn/ (https://msopentech.com/blog/2014/11/12/msopentech-alljoyn/)
For securifi to survive or do better including AllJoyn may be the way to go ... if from what I have read/understood having a simple zigbee/zeewave hub with AllJoyn will open up all sorts of possibilities. Coupled with voice activation and voice recognition and the lack of these features on Almond+ we may not have what we need by the time A+ matures into a useful product. Of-course AllJoyn is in its infancy, mfrs have already adopted this into HA Servers and it is a matter of time that we'll see more AllJoyn devices for HA considering this has support from all the major electronics mfrs! Something to delve on!
The Amazon Echo (http://www.amazon.com/dp/B00X4WHP5E/ref=ods_gw_d_s_h1_dplr_niv?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=desktop-hero-kindle-A&pf_rd_r=09SEQ0S0FGFRQJBSHTCA&pf_rd_t=36701&pf_rd_p=2118626562&pf_rd_i=desktop (http://www.amazon.com/dp/B00X4WHP5E/ref=ods_gw_d_s_h1_dplr_niv?pf_rd_m=ATVPDKIKX0DER&pf_rd_s=desktop-hero-kindle-A&pf_rd_r=09SEQ0S0FGFRQJBSHTCA&pf_rd_t=36701&pf_rd_p=2118626562&pf_rd_i=desktop)) is the ideal case for such a utility and I'm surprised they are not part of the allseen alliance!
I like the A+, but at the rate of which we're receiving support for devices, I'm willing to write off my investment here and move on. How can you implement a product which cant delivery on its basic promise. Sorry guys for long I've held out in support of A+ and will do so going forward only if I can sense some urgency on your behalf and see support for more devices that are in the market. Maybe I'm asking for too much for you to include AllJoyn, being that A+ is a small startup, but I've noticed that even this forum is loosing it fire! There I said it!
Just wanted to throw this out there!
-
Yeah, I hate to say it but all I see is a slow death for Securifi. I don't necessarily consider the investment as a complete loss, as it is still a pretty good high-speed wireless router, if nothing else. It would be nice if the device support was updated more often, and to have users willing to do a lot of the testing and most of the grunt work, it seems a bit off that the idea isn't being actively pursued (at least from the outside that's how it looks). I don't think I've seen anyone from Securifi staff post here in over a week, which is troubling as well. The other possibility of course is an acquisition, but that seems a bit out there. I'm hopeful that things will turn around, but I'm prepared to accept it if they don't.
-
The Almond Plus is not a "be all, end all" product.
It IS a WiFi router that can do some home automation via Zigbee and Z-Wave.
The list of supported sensors will grow, Rules will get better, Apps will improve. Certainly not as fast as folks might want, after all, we want it all working right now. Even so, much can be done with current units.
The Allseen Alliance is growing but it will be some time before it supports "smart home" tech.
-
My issue, or concern if you will, is that Securifi as a company fails, then we are all left holding on to unsupported and potentially dead end hardware. I'm not saying it will happen, but I'm certainly not getting a warm and fuzzy feeling from the current lack of communication, which is why I posted what I did. I'm happy enough now with how it works, as I haven't even tried using rules yet, but I'd love if it worked better.
The point of this thread is that there are people willing and able to help test and debug new sensors for free, but we haven't gotten a 'no thanks' from Securifi, much less a response at all. That's what concerns me.
-
Hi all,
I am not very concerned about the insolvency of Securifi as a company - they seem to be doing well. However, it does seem that they are stretching their resources pretty thin. And I do miss the omnipresent @Lars with the updates and communications.
Almond+ was marketed as being "open" during kickstarter phase. That claim is even still here -> http://www.securifi.com/almondplus (although in a more confusing context, i.e. Open = Works with your favorite brands [wtf?]), i would only dream for them to open-source their firmware, even though bigger companies have done it in the past with routers, e.g. Linksys WRT54GL. However, at least, open SDK and toolchain would be nice. I would like to get a hold of some of the openwrt packages, e.g. motion.
But, ultimately, you are right @rpr69, bringing new sensors into Almond+ ecosystem seems painfully slow. I haven't dug into the HA stuff - i just recently got some Schlage BE469 locks (which semi-work with A+). Even if I wouldn't know how to introduce improvements to HA modules ( although i would definitely like to take a stab at it), Most of the backers are techie enough to come up with some nifty addons and fixes to existing issues.
On a semi-related note, i have couple XBee Pros laying around, i have couple sensor design ideas, and boy, wouldn't it be nice if i could have them be able to talk to A+ natively (and not through a modchan hack)
I like the router, i just wish that the process to v1.0 and v2.0 software was faster, more open and transparent.
Andy
-
My issue, or concern if you will, is that Securifi as a company fails, then we are all left holding on to unsupported and potentially dead end hardware. I'm not saying it will happen, but I'm certainly not getting a warm and fuzzy feeling from the current lack of communication, which is why I posted what I did. I'm happy enough now with how it works, as I haven't even tried using rules yet, but I'd love if it worked better.
The point of this thread is that there are people willing and able to help test and debug new sensors for free, but we haven't gotten a 'no thanks' from Securifi, much less a response at all. That's what concerns me.
Securifi is ok financially (take a look at the PTD papers filed in India & TW then do a little digging) but IF something should happen, we would be stuck just like we would be with any product from a defunct vendor.
The Z-Wave alliance has rules about what can be made public, that's why Open Z-Wave came into existence. There are something we just aren't going to have access to, that's just the way it is with Z-Wave. Now there are plenty of folks that have reversed engineered a lot of Z--Wave info and that's out there if you look for it but doing so goes against Securifi's Terms and Conditions.
Same thing holds true with certain driver info as it relates to Realtek. @Lars mentioned as much in a few posts. Then there is the whole buy out thing of Realtek and what is happening there. Bottom line, Realtek strong urged Securifi to use a specific version of OpenWRT and not something newer. The original chip selection by Securifi had them sticking their neck out a bit (a few articles out there about the chip selection concern) and I doubt they are going to go against the chip manufacturer's recommendation.
So, we have a toolchain and an SDK. Looking at the startup files and log files, we can get an idea of what is going on and work with that. What we can't do is mod haserver code.
Securifi has been pretty willing to look at new sensors if someone sends them something. My experience with direct technical support has been very positive and timely. (i.e. sending logs, exchanging emails)
No, there isn't as much "presence" as there was with Lars, but to be honest, there isn't much user action here on the board either.
Every specific issue I have, incorrect sensor management or reporting to IOS or Android Apps, is being worked and for all I have a workaround. My voice response, shell scripts and apps are all working and I don't see any major stumbling block with Open HAB integration or integrating with several other open source options.
IF someone is actually going to work up a new sensor, I don't see a problem with getting that done either. Use the existing command classes, identify the unique manufacturer specific info, generate the XML info needed, identify the hooks for the server code and send one to Securifi. Have at it.
-
There are two areas to this. One is what we were promised and what we have got. The other part is what do we do with what we have got.
The first part, since you were a kickstarter backer is something you already know. The hardware is excellent and they delivered more than what they promised. It's the software where I am let down. I looked at the first version of the ios apps of all the hubs released since SmartThings was launched. I checked out Smartthings, Wink, Staples, Revolv and a lot more I don't remember. None of them launched without a way to organize your devices. Here, we can't even re-order them. I have a very few z-wave devices and even I think the organization could be better. I can't control both my thermostats from my computer because of a CSS bug. I have kept my needs to a minimum and I can live with this. I am still very disappointed that I can't use IP devices in rules. To me that was the biggest potential with Almond+ and I have made my peace with the fact that nothing is going to come out of that. Long story short, while I believe that every kickstarter backer has an amazing hardware given the price, they still have valid reasons to feel dis-satisfied.
The second part yes, I think you have gone a long way to try and understand how it works. In fact, I come to this forum solely to see your posts and then plan to come back and work on it. But the SDK is not something that a lot of people can easily work with. And if I do want to add a sensor, I have no idea where to start. I have a dual relay that I am desperate to get it to work, but I don't know whether the z-wave commands are supported or not and what is the XML that I need to come up with. For example, to me it seems like these all should be supported
(http://i.imgur.com/LS3947d.png).
Where do I check that? I could not find a documentation that gives an example of a sample device and how to add an xml. A lot of it requires me to figure it out. I would like to do it, but unfortunately I end up having to delay it due to my time constraints. It would be great, if people look at other extensibility frameworks to see how it can be made easier.
Lastly, the user engagement is a direct result of Securifi's policies; they have alienated their backers. I have been monitoring this forum for a while. Lars made sure that people felt they were being listened to. Maybe he could not address every issue, nor did he need to, but at the very least, he acknowledged the users and took efforts to respond to them. Ignore your community long enough and the users will go away.
-
Hi all! My bad, so pardon my ignorance - I've been living under a rock and completely missed "Almond+ software development" section of the blog. :o
Now, before i go nuts.., Is SDK v2.3 still current (from april 2014)? Does securifi have some kind of source control repo available with all the latest stuff? Also, anybody bricked any A+s yet? If so, how easy it is to unbrick them?
Andy
-
I was hoping Securifi would add something similar to Vera's LUUP. Part of crowd sourcing to playing around with the settings. For example, some people have been playing around with the parameters on their Home Energy Meter v2 to correct for proper power readings, reset readings at midnight, etc.
At this point, it seems like the Wink hub is going to be far more useful as an HA hub than Almond+, even though A+ was billed as the all-in-one device. At the rate of firmware support vs sensors released, the firmware will always be far, far behind.
-
I'm all for implementing device support myself -- like others have said, some of us just need to be pointed in the right direction (though more detailed instructions on how to add sensor support would be extremely helpful). I have an Aeon Labs Smart Energy Switch (http://www.amazon.com/gp/product/B007UZH7B8) and an Aeon Labs Smart Energy Monitor (http://www.amazon.com/gp/product/B00DIBSKFU). The switch works great -- connected first try, and reports energy usage. Common sense would dictate that the Energy Monitor, having only a subset of the Energy Switch's features, would be easier for the Almond+ to deal with, but that is apparently not the case as it indicates that that device is not supported.
Taking some cues from this thread, I started my own investigation. I found five copies of DeviceList.xml -- one in the root path, and four in various subfolders. All copies contain both the Switch and Monitor. I'm curious how Z-Wave devices are uniquely identified because the only fields that seem like they could possibly be unique identifiers are OZWNode and AssociationTimeStamp. I would have presumed it would be something like the ZigBeeShortID or ZigBeeEUI64, but those are both NaN presumably because these are both Z-Wave devices rather than Zigbee. But that's basically a side note as I really just want the device type supported, and surely this is defined in the DeviceType field. The Switch (the working one) has a DeviceType of BinaryPowerSwitch. The Monitor (the "not supported" one) has a DeviceType of MultilevelSensor. Not super helpful. I mean, isn't a BinaryPowerSwitch conceptually a multi-level sensor also? It does multiple things.
On another cue from this thread, I checked out /almond/config and it has its own aeon_labs folder; awesome! It has three very promising definitions: hem.xml, hem1.xml, and hemg2.xml -- I'm guessing that stands for "home energy monitor" and the defined commands seem consistent with that guess. But, how do those XML files get used? I went up one folder level and found manufacturer_specific.xml that appears to define lots of devices according to the description at the Open Z-Wave site (https://github.com/OpenZWave/open-zwave/wiki/Adding-Devices). Indeed, hem1.xml is "Aeon Home Energy Meter" with type=2 and id=9, and hemg2.xml is "Home Energy Meter G2" with type=2 and id=1c, and . So...it seems good that the device I think I have has a definition, but why does it then still show up as unsupported? One reason I can think of is that I don't actually have what I think I have -- that is, the type and/or id reported by the device doesn't match the definition in manufacturer_specific.xml. Unfortunately, I think I'm close to a dead end here though because I don't know how to check what those values actually are for the device. Is there some kind of command on the Almond+ that will list all Z-Wave devices within range, along with their product type and id? There is a whole section in the database entry for this device (and others, I assume) labeled "Device data" (http://www.pepper1.net/zwavedb/device/65 or http://www.pepper1.net/zwavedb/device/693) Is there any kind of utility on the Almond+ that will print this data out for all in-range Z-Wave devices, or is that data not present on the devices themselves? If not, it seems like I'm spending an awfully large amount of time trying to get Almond+ to do something that a $40 replacement (http://www.amazon.com/dp/B003MWQ30E) would do just fine.
So:
1) Why doesn't Almond+ support my Monitor when it seems like there is a definition file for it?
2) What can I do to work toward adding support for it?