Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - davegravy

Pages: 1 [2] 3 4 ... 37
Users / Re: CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 25, 2014, 03:06:36 pm »
Response from manufacturer:

Hi, sorry, but no there is no way to adjust how the thermostat communicates through zwave. If you have any additional questions please don't hesitate to contact us.

So... About translating set point values into Fahrenheit on the LMCE side... :)

Users / Asterisk Hacking Attempts, Firewall letting attack through somehow?
« on: November 25, 2014, 02:58:47 am »
A bit stumped by this. Alblasco can you help me out?

I launched the asterisk console (asterisk -r) and was barraged with multiple instances of this message:

[Nov 24 20:10:38] NOTICE[3002]: chan_sip.c:24905 handle_request_register: Registration from '"3551" <sip:3551@MYIP-censored>' failed for '' - No matching peer found comes up in google as a known malicious IP

I used to have SIP ports open to external but as a result of this disabled them.  The attack is still somehow getting through.

I managed to block the attack using

Code: [Select]
iptables -A BLOCKLIST -s -j DROP

Users / Re: CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 24, 2014, 06:45:22 pm »
Manufacturer responded by referring me to support for my Zwave controller.

I responded:

Perhaps my question wasn't very clear.

Your thermostat interprets commands sent over Zwave and modifies its settings (example heating termperature setpoint) accordingly. The means by which it interprets those zwave commands is what I am questioning, and is irrespective of the Zwave controller.

The zwave controller manufacturer will not be able to help me with this and will refer me back to you.

Please tell me if there is a way to change the behaviour of the CT100 so that it interprets temperature setpoint changes received via Zwave as degrees Celsius as opposed to degrees Fahrenheit (note that I'm not referring to the display units which is a different matter).

I'm not very knowledgeable about how these devices talk at a low level, but I'm assuming there is no unit (Celsius/Fahrenheit) supplied with setpoint commands by the controller, just a value, and that it's up to the thermostat to interpret it as Celsius or Fahrenheit (obvious design would be to decide this based on the unit that the user has chosen to have displayed on the LCD of the screen).

Users / Re: CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 18, 2014, 03:13:28 am »
Did you check with the manufacturer?

Emailed a while ago, waiting to hear back.

Users / Re: CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 18, 2014, 12:12:16 am »
There is nothing in the template that decides what unit the temperature is interpreted as. All my devices works as expected (I also use Celsius) and I don't recall having to do anything special.  But I do think some devices has a configuration setting to toggle the unit it interprets values as - you should read the manual for your device.


See page 5

As far as I can tell from the documentation, the device allows you to switch display units but not the units it expects as input via ZWave.

Given this, I assume I'm out of luck until/unless some conversion code gets implemented somewhere in LMCE.

Users / Re: CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 16, 2014, 01:22:10 pm »
Anyone?  Is this a case of needing to make a non - generic template specifically for this thermostat?

Users / [SOLVED] CT100 ZWave Thermostat Fahrenheit vs Celcius
« on: November 06, 2014, 10:03:40 pm »
Recently I bought a CT100 thermostat and it have it configured and responding via ZWave

The device is detected as a "Standard Thermostat" device template.

When I try to set heating/cooling setpoint temp it seems to interpret values as Fahrenheit even though in webadmin it says setpoint values are Celcius. How can I modify the behavior to allow Celcius values to be sent?

Developers / Re: Market Research
« on: November 06, 2014, 03:57:51 pm »
Also great would be the ability to detect temperature differences between inside and outside, and use a larger/smaller portion of filtered outdoor air to cool or heat the house.

I review a lot of HVAC designs for proposed commercial buildings and they all seem to be doing stuff like this nowdays.

Developers / Re: Market Research
« on: November 05, 2014, 11:00:47 pm »
I agree Posde, but one thing that's high on my (SWMBO's) wishlist in my home is the ability to have multiple thermal sensors around the house and automate-able, retrofit-able dampers such that there is a more even distribution of thermal energy.

I've played around with manual dampers to no end, and it's a very difficult (moving) target.

Developers / Market Research
« on: November 05, 2014, 05:05:39 pm »
If anyone's interested in tailoring their dev efforts to match what consumers want, here's a potentially useful poll, albeit a disappointing sample size (N=38):

Users / Re: Need some dedicated testers.
« on: October 18, 2014, 05:30:03 am »
*Implements adding new orbiter from splash screen
*Implements switching between form factors. Ex: it is on the phone skin, but you want the tablet one.
  -This is under the advanced menu on both Android Tablet and Phone UI
  -Switched smokey skin to default for Android tablet.
*Added A-Z jumping functionality to Android tablet media grid.
*multiple other smaller fixes.

Anyone besides me tested these yet?

Tested UI switching on QT4... seems to work as per your youtube video.

Can't seem to load the advanced screen on QT5. Also can't seem to change styles on QT4 anymore.



Users / Re: [12.04] OpenZWave Aeon ZStick Issue
« on: October 17, 2014, 04:21:38 am »
Davegravy, FYI,
Please keep in mind that the z-wave implementation in Lmce 12.04 (based on open-zwave) is a lot different than the one in Lmce 10.04.
In comparison, the open-zwave based version has a lot more features and is very well maintained, but is also much pickier when it comes to its zwave-network setup.
Open-zwave needs a very good and stable z-wave network to work good, so if things worked in Lmce 10.04, that does not necessary mean they work as good in Lmce 12.04.


I appreciate it's different but I assumed that the goal is for openZwave to be just as robust if not more robust than the proprietary driver. I don't know where they are in development, and it's totally understandable if the trouble I'm having is a bug that hasn't been worked out or something, but I'm surprised and I guess a bit disappointed if the design of openZwave is such that it requires a more stable network to work well.

Users / Re: [12.04] OpenZWave Aeon ZStick Issue
« on: October 15, 2014, 04:10:44 pm »

Recently i used a extension cable to get my aeon-labs z-stick away from my core, more towards my z-wave network, so there was no interference from my core on the stick.
Before it was plugged in the back of my core. I also positioned the z-stick vertikal.
I found a article online, discribing this as the recommended way.

After some testing i found out that my z-wave network responded much better.
Even a battery operated sensor, which previously responded every now and then, now responce great.


Hi RayBe,

Thanks for the suggestion, I think it's already vertically oriented however. This test node, as well as the 30 or so others that I have in my house, have been behaving beautifully over the last year in their current config / placement /etc.  I don't know if it is my Zstick that is failing, or recent changes to the LMCE Zwave implementation, a prankster hacker, or something else that is to blame, but something is definitely up.

The test node survived the night this time, and has about 12 hours of uptime now. I'll keep an eye on it.

Users / Re: [12.04] OpenZWave Aeon ZStick Issue
« on: October 15, 2014, 07:25:30 am »
Thanks Raybe.

I haven't added back all my other nodes yet, so I still just have the one test node in my network.

This morning I couldn't control that test node anymore. From the logs it looks like overnight my CORE decided that the node was dead after several attempts to reach it. I tried a router reload but that wouldn't bring it back. A reboot fixed it however.

The node represents a lamp module which is 5ft away from the Zstick so it shouldn't have trouble communicating to it. I mistakenly deleted the log which shows the point last night where the communication died, but I'll wait to see if it happens again and post the log if it does.

Users / Re: Need some dedicated testers.
« on: October 14, 2014, 06:30:16 pm »
First, thank you to everyone who has spent a couple minutes providing feedback on qorbiter for android. After some serious thought and discussion as well as observation, I think its time to slow this train down a bit. I dont mean development will stop. Not in the least bit. But, I am guilty of jumping to the shiniest new object. Also, some other things need to be taken into consideration. Qorbiter now has binaries for:
*x86 Linux - Desktops
*Arm linux - Raspberry pi's

Other platforms:
Windows is touch and go at this time...
Sailfish ive just not gotten around to
Same with blackberry
Made my first iOs app yesterday

This means there needs to be both active skin development and testing for all these platforms (no, not right now!) But in light of this, I think  I as a developer have a duty to take this a little more seriously, as its graduated far from a prototype toy. So, with all of that long winded statement out of the way, im proposing that we start working using the concept of agile development. There are many ways to do this, but I will share with you my understanding of this process.

1. Backlog - This is basically the entire wishlist of features. Everything you can think of. It supposed to be weighted by difficulty. A challenge here is to decide on how we deal with features across platforms.

2. Backlog Grooming - Taking stuff from the wish lists and putting it on the sprint task list. You are careful not to overload the sprint with too many tasks. the goal is to get things working within the sprint.

3. Sprint - Development time where things are developed. It could be bug fixes, new features, or a mix of both.

4. Sprint demo - Demonstration of sprint implementation

People involved.

Product Owners - This would normally be the client. They fill the backlog, weight the importance of features (1-5), and test features after a sprint. In this case, its the linuxmce community.

Scrum Master - This person directs the flow of traffic. Part project manager / Part developer the help with sprint planning and normally moderate daily standups (something we cant do)

Developer - Implements features and fixes bug according to the sprint plan.

SO, with all that said, basically I want to do something similar to this where...

*QOrbiter feature list / backlog is put in wiki.
*Tasks get groomed from feature list in wiki, to active tickets in trac.
*Tasks get completed over a 2 week sprint, people test
*Rinse repeat

The tasks could be picked by the community every two weeks for most important focus.

More stable releases
Targeted feature completion.
Easier update paths

Slower updates
Community decisions can be slow
Requires involvement of everyone (cause you know, its your product)

So, let me know what you think, but I seriously leaning this direction with the first tasks being
*Improve initial installation experience.
*Fix skin detection to properly detect phones / tablets
*Add remote screens
*Fix remote errors in sizing, commands sent.


Seems like a great direction to me.

Pages: 1 [2] 3 4 ... 37