Line-voltage baseboard heater thermostat

Thanks peterluc8080. You know, if we fail our funding objectives, Kickstarter won’t charge your credit card, so there’s no risk involved. You’ll know in three weeks if you bought them or not, but if you make the commitment now, it’ll be that much more help to reach our objective ! Every little bit counts…

Thanks !

Martin

[quote=“T1000, post:38, topic:179652”]There are two answers to this question : the configuration and provisioning app allows for a custom server location to be specified. One could replace CaSA’s server with his own and given that the server has the proper config, the devices would respond. At this time, this scenario poses a serious encryption and security issue we’re not yet sure how to handle. Everything we do is guided by the need for proper security - not exactly something home automation is famous for - and there are scenarios where exposure reaches an unacceptable level. I can’t comment on Vera’s case specifically as I am not a programmer, but it’s evaluation is on the to do list.

The second answer is the one that should satisfy most users : we plan on developing plugins to have a user’s HAN gateway interact with our servers to send and receive commands. This is a better scenario as it maintains the dual layer encryption between the device and server and it allows the user to leverage much more advanced features, that would possibly be impractical to implement directly on the HAN gateway. This development was identified as a secondary funding objective, but since there has already been a number of request I see that this may get fastforwarded up the list…

Hope this answers the question ![/quote] So as of now there’s a chance that the remote control of these thermostats will rely entirely on a proprietary cloud service? Honestly I don’t feel confident enough in a kick-starter ability to guarantee that the cloud service will be available one year from now. If you can provide an open web service API to directly control these thermostats then I’m in. Customers should decide to enable it or not from the touchscreen local user interface. I feel that the link to the web-based cloud service would be at least as weak (encryption-wise) as the link to talk directly to a HTTPS server running on the thermostat with personal certificates.

I’m thinking the same as lodup29… I dont want to buy it to found out one year later that I cant control it thru Vera and if by that time a new product goes on sale, I will be I will fuck… I will wait.

I think the same, if i can’t control it from vera…it’s not good for me. I passed 1 year to make my own android interface for my home automation to control light, pool, energy monitor, etc…If i can’t integrate this thermostat to my system…i pass. I need 11 thermostats, i want all of my thermostats react with other hardware. (Window sensor, door lock…etc)

[quote=“mitnick29, post:44, topic:179652”]I think the same, if i can’t control it from vera…it’s not good for me. I passed 1 year to make my own android interface for my home automation to control light, pool, energy monitor, etc…If i can’t integrate this thermostat to my system…i pass. I need 11 thermostats, i want all of my thermostats react with other hardware. (Window sensor, door lock…etc)[/quote] Well I think that it’s very likely that you’ll be able to. The issue is that the Vera hub will talk to a cloud server which will talk back to your thermostat. Developing a Vera plugin to talk to the cloud service is likely fairly straightforward and I’m sure these guys will come up with it by the end of the year. The issue for me is what’s left of my thermostats if these guys go out of business? These thermostats become nothing more than fancy touchscreen enabled locally programmable thermostat?

You’re right. If the server crash, the thermostat is like other standard thermostat. I don’t want to buy 11 thermostats at 150$ if my Aube at 35$ do the same…Come on T1000 … give us a solution for this problem ???

Thanks!

All right, let’s slow down here people :slight_smile:

lodup29 is correct : the ability to control Caleo through your Vera - or any other gateway for that matter - is a simple question of API. As was previously stated, the campaign aims at developing these APIs, not the product itself. The manufacturing run is already in progress, Kickstarter will have no bearing on the product reaching market as we have angel investors and venture capital to keep us going.

Now, you’re all pretty technical, so I’ll skip the dance and go straight to facts : if the cloud service disappears, you’ll simply have to point your thermostats towards another server. That’s already implemented, in fact you could this tomorrow morning if you wanted to. But here’s the catch : in order to make this device as secure as can be, we’ve elected to have it talk to a dedicated server and then leverage that server’s capabilities to implement much more complex behaviors than most HAN gateways could ever hope to achieve, including demand-response capacities. If you chose to bypass this and control them directly, you’d be left with nothing more than a fancy remote control for your heaters. I’m sure some of you guys have setups that are capable of handling this and make it efficient, but the fact is that the vast majority of people don’t. These things aren’t light switches or door sensors, in the sense that their hacking or malfunctioning can have a very serious effect on your house.

We feel it’s our responsibility to ensure we sell something that is secure and safe, but we’re not naive either. We don’t want anyone to end up with a wall-mounted paperweight if we were to go under, so the capacity to have the device communicate with a third party is built in. All I’m saying is it probably won’t make much sense to use it unless we’re gone for good :slight_smile:

Hope that clears that up ? Keep 'em going if you have more questions !

M.

[quote=“T1000, post:47, topic:179652”]These things aren’t light switches or door sensors, in the sense that their hacking or malfunctioning can have a very serious effect on your house.

We feel it’s our responsibility to ensure we sell something that is secure and safe, but we’re not naive either. We don’t want anyone to end up with a wall-mounted paperweight if we were to go under, so the capacity to have the device communicate with a third party is built in. All I’m saying is it probably won’t make much sense to use it unless we’re gone for good :)[/quote] What’s highest level of granularity for the information exchanged between the thermostat and the server. For example (highest to lowest)
[ul][li]Weekly planning[/li]
[li]Current room temperature target[/li]
[li]Duty Cycle[/li]
[li]Raw On/Off[/li][/ul]

[quote=“T1000, post:47, topic:179652”]if the cloud service disappears, you’ll simply have to point your thermostats towards another server. That’s already implemented, in fact you could this tomorrow morning if you wanted to.[/quote] Can you provide detailed instructions right away on how we can achieve this?

[quote=“T1000, post:47, topic:179652”]in order to make this device as secure as can be, we’ve elected to have it talk to a dedicated server[/quote] I feel that doesn’t make it more secure as one can do whatever he wants with it through the server. That’s 2 hackable links (Thermostats-Server and Server-Client) instead of one. [quote=“T1000, post:47, topic:179652”]These things aren’t light switches or door sensors, in the sense that their hacking or malfunctioning can have a very serious effect on your house.[/quote] Well remotely programmable thermostats have been done before and thermostats working with HAN gateways too. What’s so different with these thermostats that it’s a safety hazard to do so?[quote=“T1000, post:47, topic:179652”]implement much more complex behaviors than most HAN gateways could ever hope to achieve, including demand-response capacities. If you chose to bypass this and control them directly, you’d be left with nothing more than a fancy remote control for your heaters[/quote] I think that most folks on this forum are dealing with utilities which are not about to implement demand-response mechanisms. Utilities have to deal with people not capable of understanding that this is on a voluntary basis and that the effect on the room temperature will be negligible (there are a lot of people out there who think that smart meters cause cancer). I think it’s a plus that these thermostats are demand-response ready but as most folks on this forum I’m just looking for a smarter line-voltage baseboard heater thermostat.

What's highest level of granularity for the information exchanged between the thermostat and the server. For example (highest to lowest)
Weekly planning
Current room temperature target
Duty Cycle
Raw On/Off</blockquote>

The programming is handled by a timetable, but there’s a bit more going on between the device and backend. We monitor humidity level, firmware version, night light level, time/date sync and other goodies. Frankly, we’re not sure yet how much of this should be disclosed and to what level of detail. While I appreciate your curiosity is justified, you’ll understand that this being a commercial endeavor we have to keep at least a tiny bit of lid on things…

Can you provide detailed instructions right away on how we can achieve this?
The provisioning app has a field to configure this. You'd just need to run it again and replace the default handling.
I feel that doesn't make it more secure as one can do whatever he wants with it through the server. That's 2 hackable links (Thermostats-Server and Server-Client) instead of one.
Well, that's one way of seeing it, and I'm not going to argue because nothing is secure. It is as secure as your best effort. Anyone arguing otherwise is a fool. That being said, our decision was meant to circumvent the biggest flaw of all, the user's home network. Every device out there assumes that your WAN is secure and configured properly. We know that's just not true. So we implemented a second level of encryption to cover the use of a device in an unconfigured or improperly protected home network. If you ask me, the instant you have a link between two devices, your security compromise has started, so from that point on it becomes a matter of opinion - and statistics :)
Well remotely programmable thermostats have been done before and thermostats working with HAN gateways too. What's so different with these thermostats that it's a safety hazard to do so?
There isn't a single thermostat out there that is an electrical control devices. All thermostats - including the most sophisticated ones - are merely remote controls for integrated systems that have their own failsafes and control mechanisms. We swith an electrical load - and a high one - on and off. Obviously we have the necessary on-board protections to ensure that ultimately the laws of physics will prevail on any wrongful intentions, but one could argue that shutting the heating off is a probably a bigger threat to your house than trying to raise it through the roof. In short, we're playing a role that we feel has a much bigger security profile than a light switch or a door sensor... But again, as previously stated, one is free to disagree with that stance.
I think that most folks on this forum are dealing with utilities which are not about to implement demand-response mechanisms. Utilities have to deal with people not capable of understanding that this is on a voluntary basis and that the effect on the room temperature will be negligible (there are a lot of people out there who think that smart meters cause cancer). I think it's a plus that these thermostats are demand-response ready but as most folks on this forum I'm just looking for a smarter line-voltage baseboard heater thermostat.
While I agree on the timing argument, we have been involved in discussions with a number of utilities and I'd have to tell you that all of them are involved with demand-response and peak-shifting in one way or another. The hardest part of implementing this is to obtain significant assets for a minimal investment, so that's typically achieved on the distribution side where most people don't realize it. That being said, I understand that it might not be at the top of some people's list as a feature, but it's actually a super important one as it is part of our revenue stream.

I don’t want to sound defensive, I’m not trying to excuse anything as there’s been extensive research, reflection and consultation on every aspect of our device and it’s environment. Not to say it’s perfect, in the end it’s nothing but a bunch of compromises, but it is what should prove the most efficient for energy management, easiest to use for the average user and as secure as we can make it without jeopardizing function. That being said everything discussed here is reported back to the development team of which I’m part of so this discussion, as many others, will have an impact on the course of our development…

M.

[quote=“T1000, post:49, topic:179652”]The provisioning app has a field to configure this. You’d just need to run it again and replace the default handling.[/quote] I meant what needs to be implemented on the server side, the substitute for your own server.[quote=“T1000, post:47, topic:179652”]if the cloud service disappears, you’ll simply have to point your thermostats towards another server. That’s already implemented, in fact you could this tomorrow morning if you wanted to.[/quote][quote=“T1000, post:49, topic:179652”]Frankly, we’re not sure yet how much of this should be disclosed and to what level of detail. While I appreciate your curiosity is justified, you’ll understand that this being a commercial endeavor we have to keep at least a tiny bit of lid on things…[/quote] Maybe there’s a misunderstanding here. How could one switch the server if you can’t disclose how the other server is expected to communicate with the thermostat?

[quote=“T1000, post:49, topic:179652”]

I feel that doesn’t make it more secure as one can do whatever he wants with it through the server. That’s 2 hackable links (Thermostats-Server and Server-Client) instead of one.

Well, that’s one way of seeing it, and I’m not going to argue because nothing is secure. It is as secure as your best effort. Anyone arguing otherwise is a fool. That being said, our decision was meant to circumvent the biggest flaw of all, the user’s home network. Every device out there assumes that your WAN is secure and configured properly. We know that’s just not true. So we implemented a second level of encryption to cover the use of a device in an unconfigured or improperly protected home network. If you ask me, the instant you have a link between two devices, your security compromise has started, so from that point on it becomes a matter of opinion - and statistics :)[/quote] Even if my home network was completely non-secured, if the communication between the thermostat and the server relies on the same encryption as the communication between the client and your server, how is it less secure? It’s like putting 2 resistances in parallel. No matter how high the second resistance is the equivalent resistance will always be at least as low as the lowest one. The best effort for me would be to get rid of that second resistance if the user wants to and to beef up the remaining one if the user wants to (ex: Encrypted and authenticated VPN encapsulating HTTPS) which I’d probably wouldn’t as I feel that HTTPS is secure enough. I’m not saying that your scheme is not secure. I’m just saying that security should not justify that scheme.

[quote=“T1000, post:49, topic:179652”]

Well remotely programmable thermostats have been done before and thermostats working with HAN gateways too. What’s so different with these thermostats that it’s a safety hazard to do so?

There isn’t a single thermostat out there that is an electrical control devices. All thermostats - including the most sophisticated ones - are merely remote controls for integrated systems that have their own failsafes and control mechanisms. We swith an electrical load - and a high one - on and off. Obviously we have the necessary on-board protections to ensure that ultimately the laws of physics will prevail on any wrongful intentions, but one could argue that shutting the heating off is a probably a bigger threat to your house than trying to raise it through the roof. In short, we’re playing a role that we feel has a much bigger security profile than a light switch or a door sensor… But again, as previously stated, one is free to disagree with that stance.[/quote] … and the end result is exactly the same. I feel that the fact that the end control for the heating element is not within the thermostat has very little to do with the choice of the remote control capabilities of the thermostat.

Well, I believe I have done the best I could to answer your questions. I appreciate your take on this but since it’s turning into a debate of opinions, I’d rather not venture there and concede that our device does not match your needs.

Thanks for the input !

M.

[quote=“T1000, post:53, topic:179652”]Well, I believe I have done the best I could to answer your questions. I appreciate your take on this but since it’s turning into a debate of opinions, I’d rather not venture there and concede that our device does not match your needs.

Thanks for the input !

M.[/quote] Agreed. This is getting nowhere.

i am not a technical guy. all i want is a wifi enabled thermostat that i can simply put in place of the existing programable line thermostat, link with my wifi network, load an app on my phone, ipad, laptop, and control the thermostats. last thing i need is to have to rely on a third party server to control the thermostats.

why is it so difficult to get manifacturers to figure this out and build simple line thermostat with a wifi link? there are plenty of models for furnaces and 24 v.

my cottage has 12 thermostats. all i want is to repla?e them all, myself with wifi devices… i considered alternative (aube relays and 24v thermostats, Econnect, etc…). these are expensive options and require electrician.

if Caleo will allow me (not you) to control the thermostats myself ( not through your server) then i will buy 12 immediately.

Why the thermostat is WIFI and not Zwave?
Is for accommodate more people?

Hello mitnick29. Yes, very simply put, it’s as sad a reason as that.
goldbug, same argument here : Line-voltage thermostats are a tiny market, z-wave users are a tiny portion of that tiny market… We’re not even talking tens of thousands here.

A number of people in various discussions wondered why no one was making this, the answer is simple : it makes absolutely no sense. Yet we didn’t let that stop us as we saw an opportunity on another level : turn it into an energy management asset.

For that reason - and all others outlined earlier - it means that Caleo has to rely on a backend, it’s simple logic really. If we want this device to be accepted by a wide user base, it has to be simple and it has to work out the box. You can read refer to lodup29’s discussion to see more detailed answers from me. I have no problem in conceding that this is not perfect for everyone as I know - emphasis : I know for a fact - that this is the only way to create such a device and support it during it’s expected 10-years-plus lifetime. Read it again, it doesn’t mean you won’t control or integrate it with your home automation, but like a growing number of devices out there, you’ll have to rely on some remote intelligence to make this truly efficient.

This is maths and economics, not matter how we feel about it, we went the only way that wasn’t a mandatory bankruptcy :slight_smile:

I understand that some feel uneasy at the risk of us disappearing with our cloud service, but as I said before there are provisions to circumvent this. We are backed by serious people with serious money, we feel we have a good chance at making this work. Moreover, I hope that this discussion will have outlined how transparent we are with this business !

Cheers !

M.

i dont get it. no market. In Canada ther must be millions of households with baseboard heaters. in Quebec alone, the majority of houses have baseboards with several thermostats.

last thing i need is to trust a third party about my home comfort. if i need connection to an outside server, Caleo is not for me…i pass.

back to conssider aube relays and 24v thermostats

T1000 - Thanks for running with an idea and making it a reality. Very impressive that you saw a need and are actually coming out with something that people will be using in the near future.

I’m not an electrician by any means so I thought I would ask, if I have a single thermostat (in my kitchen) that’s controls 2 - 240V baseboards, does that require additional equipment or would the standard controller be able to handle this load?

Thanks again!

[quote=“goldbug, post:58, topic:179652”]i dont get it. no market. In Canada ther must be millions of households with baseboard heaters. in Quebec alone, the majority of houses have baseboards with several thermostats.

last thing i need is to trust a third party about my home comfort. if i need connection to an outside server, Caleo is not for me…i pass.

back to conssider aube relays and 24v thermostats[/quote] If somebody else is about to do it I’d bet on Honeywell. If enough people are asking (that’s what I did) they might jump in. They currently have the RedLINK line but it’s far from perfect (for one thing it apparently doesn’t integrate well with other home automation systems, if you’re on this forum I guess that’s a deal breaker).