I received this email today, the 2yr warranty on my Owl Intuition expired 2yrs ago and I haven’t used the service in over 3yrs so no real loss to me.
If any Owl users want to use their products with emoncms rather than pay the subscription (not that it’s alot of money), it has been done before via emonhub, if there was enough demand maybe we should consider a including an Owl interfacer in emonhub.
Dear Customer
The 2 year warranty period of your OWL Intuition product has now expired.
During this time you have had free 24/7 access to all your product data held by our servers, free technical support and software upgrades.
Unfortunately, all of this costs and it is not economically viable for us to continue providing these services for free indefinitely.
Therefore, from the 1st January 2018 we will be charging a small subscription of £19.95 for two years’ use of all the above services following the expiry of the initial 2-year warranty period. To ensure uninterrupted use of your OWL product, please go to theowl.com :: Subscriptions to pay your subscription before 31st December 2017.
Your two years subscription will provide unlimited online support, all software and firmware updates and 24/7 access to your data, for the next two years - alongside any general improvements to the services we provide. Systems without a subscription and outside the initial 2 year warranty period are due tobe disconnected from the 1st January 2018.
Our apologies for the necessity of this, but we have provided an outstanding free of charge service for a significant number of years. We hope that we have provided a level of service that you feel is worth continuing with.
I’m very concerned abut this policy changes. I’ve got also an OWL intuition reporting via UDP to my server.
It wold be great to create an interface to Open Energy, but I’m afraid if you don’t purchase the service, the OWL will simple be deactivated… You can’t change the address to report to other server unless you have previous service with they. Isn’t it?
Afternoon, I arrived here because I’ve just been chasing up on a similar email that I received and a search led me here.
While I have no problem paying for a service when it’s agreed up front, and while it’s not much, …well let’s just say that we are in discussion and I’m looking for a way not to have £450 worth of plastic and metal bricks if the conversation goes the wrong way…
So, having looked a while back at the interface docs that jeremy references in his link I always assumed that it would be possible to have an alternative local control in place. Trouble is I’m not a software developer (happy to hack raspberry pi solutions together and plug building blocks together with configuration) but to do everything would be prohibitive for me.
If I understand correctly from a brief glance over the website the pieces are about to get monitoring info from an owl installation but it doesn’t sound like emoncms was designed with control in mind (given that the site is open energy monitor this isn’t such a big surprise). What I am concerned about is loss of control of the programmatic elements of the solution. I’m not fussed about web based remote control, never have been. In fact I’d rather do my remote control via a unit behind my firewalls so remote access is protected through one single route along with anything else.
So my question is how far from replicating the basic monitoring and control functions of the owl system would emoncms be?
Hi just joined this community after reading your post Paul. I have intended to try setting up emonhub with owl for several years and just been relying on the OWL app todate. I setup my rPi with the emonhub image the other day and now looking at how the Owl UDP messages can be integrated.
If an easy to access Owl interfacer in emonhub is possible it could simplify this route for a number of people. I know several colleagues and a few family members using owl so would be great to suggest to them an easy feature rich monitoring solution.
As it is, I’ve decided to pay for a couple of years owl service for now, but not overly confident in their lack of updates or service uptime to be honest.
I’ll be digging a bit more on this forum for those that have put together their own solutions if there isn’t a configurable option likely to be offered.
Any help or pointers much appreciated.
PS I’m an electronic engineer by profession rather than a software enginer, so unless I get to follow detailed instructions or download plugins I get out of my depth fast trying to write source from snippets.
I too have had this email and i too am disappointed with their choice to make it a paid service, i dont think this is very fair for persons like myself that purchased it years ago believing it would stay a free service paid for by the original purchase price. I have been emailing their support team and they confirmed that with no subscription the owl intuition device will no longer work and become a paperweight so i’m pretty keen to look for alternative options.
Agreed. I don’t mind paying for a service if it’s known up front and part of my decision process.
That aside, the good news is, having spent a few days investigating, there is currently a way to control it and get most of the programmability. Therefore should you decide not to pay the support fee it’s not quite as bad as just button control on the remote control sensors.You could also get remote control at a stretch but that’s unlikely to be from a phone - read on.
The bad news is it’s a command-line like process as it’s simply using a UDP utility to use the commands given in the published API.
If you’re not into command line stuff then probably of little value. Equally I have no idea if it works to change Electricity monitoring sensors because I don’t have them installed. For me it’s the heating part that’s most important. I’m sure a developer could string together a program or indeed something like a PI based webserver to interact and display an interface with the same functions as the OWL service but that’s not a short term solution.
Interpretation of monitoring data will need something else to collect, collate and provide reports but that’s what OpenCMS is all about I think. To be honest, I’ve found that while it was initially fascinating and allowed me to tweak heating a bit, from 3 months in I never really looked at the graphing again for any practical purpose.
Having just paid to replace on of the sensors before getting the email I am a little annoyed, I had come to terms with the lack of actual intelligence and weather compensation that the Owl System demonstrates and then get kicked in the teeth with the subscription.
Legally this being such a key deciding factor it would be considered an unfair term:
a because it was buried in Ts&Cs and not declared openly
b because no cost is mentioned in the Ts & Cs.
My primary concern though is that this is a signal of the company’s declining financial health and this is supported by the lack of any new products on their web site which indicates that they have no R&D spend available or do not care, companies who do not innovate do not survive, this would suggest that the whole service is at risk at some point in the future.
This I would suggest is a good grounds for including an Owl Programming and control interface, I have been looking for the last couple of months for something to run on a Pi but to no avail and I am maxed out with a house renovation and 2 children.
Hi. I just joined the community to post about this.
I’m afraid I’d been ignoring the demands for subscription thinking they were spam. D’oh!
I originally chose OWL because of its published API - that was over 4 years ago and I never did get around to doing anything with it. Probably about time I got started. As with other posters, my main concern is losing the ability to control my heating system - monitoring is just a nice to have IMO.
I will have a crack at a Raspberry Pi based interface to the Network Owl with a simple HTML based control panel. Starting with basic real time operations (comfort, boost, standby, away) and bringing in programming etc in later versions. Personally I would prefer an ESP8266 based solution or maybe just a bit of software to run on my network drive, but I think a RPi would be easier for most people to get their hands on.
I’ll post any progress here and make my software freely available if I have any luck.
Basic control turns out to be ridiculously simple.
You’ll need to get your UDP key from the Owl Intuition web dashboard, quick before your subscription expires. Click “System” at the top of the page , then scroll down to “Advanced Settings” and click “Setup Data Push”. Make a note of the UDP key shown and keep it safe.
Then use a UDP console (I used Packet Sender, which is free) to send the following to your Network Owl’s LAN IP address on port 5100. Note the last parameter “UDPKEY” should be replaced by your UDP key. The basic commands are very self explanatory:
Rob,
if you’re a coder, then it would be good to see something like that.
What you describe is the command facility that I was referring to. It works fine. I’ve been through most of the commands and have updated the API documentation with my discoveries (mainly round the newer versions of firmware, tho obviously it’s not verified). Happy to drop you a copy if that helps you not have to waste a couple of hours working it out.
To be honest, with UDP sender allowing you to send groups of saved commands even programming the clock settings becomes relatively easy once you have the basic sequence in there.
Gary,
It’s not officially updated. I’ve taken what existed into text format and updated it having spent a few hours trying out all the commands and then getting them to work so I have my own reference.
So 3 caveats,
It’s not 100% but of course anyone would test what they use from it so it will save them the bulk of the work.
I haven’t looked at the electricity monitoring stuff, as I haven’t got sensors installed.
If there were any new commands introduced in later firmware versions, of course it won’t have those.
It’s a long time since I coded but it’s interesting to see which of the commands ignore certain things and which don’t and to speculate on how the interpreter has been put together…
I’ll run through it this weekend and make sure there aren’t major typos etc and then anyone who’d like a copy in the next few weeks, happy to email to them if they send me their email address. I’m not going to put it up anywhere as I don’t want to create confusion when people are looking for API documentation and I don’t want to antagonise the OWL guys. In fact I’m planning on sending it to them in about a month once their New Year is over and requesting them to verify and add what’s required. They either will or won’t but as the basics haven’t changed much I see no reason that they would block the idea - manpower might be a different question of course.
Through the documentation online from OWL i have accessed and updated my heating settings using java and UDP. Of course there is nothing to stop OWL from downloading an update to the Unit to stop this type of access so that you are forced to take out a subscription to the paid service or am I just being concerned about nothing?
The exciting bit is that having this interface now I can think about integrating it into the rest of my Zwave home automation system, which opens a number of possibilities i.e. If the front door is open ignore the drop in temperature until the door is closed.
The user who made the post you replied to hasn’t been on the forum since January of 2019,
so it’s possible you may not get an answer for quite some time.