Messages

1

Developers / Re: ZWave stack fixes

« on: July 17, 2013, 06:55:38 pm »

No I haven't in the context of LinuxMCE. Only browsed the code a bit in the Google repository for the purpose of gaining a better understanding of ZWave. It does appear to have a more complete implementation, but I'm not familiar with how it get integrated into LinuxMCE.

Regards,
Stefan

2

Developers / Re: ZWave stack fixes

« on: July 17, 2013, 06:39:47 pm »

Thanks. I created Ticket #1844 and attached the svn diff.

Regards,
Stefan

3

Developers / Re: ZWave stack fixes

« on: July 17, 2013, 06:15:21 pm »

The changes are on the current Zwave stack.

Everything was tested using a Honeywell YTH8320ZW1007 thermostat.

Thanks,
Stefan

4

Developers / ZWave stack fixes

« on: July 17, 2013, 03:19:23 pm »

Hi,

Where should suggested fixes be sent? I made the following updates:
- fixed logic to not overwrite the setpoint in the State string with basic reports
- added functionality for more setpoint types (e.g. economy heat, economy cool)
- added polling of thermostats for the setpoint and mode
- added support for floating point setpoints reported by thermostats
- made the code a bit more legible by defining constants for the setpoint types

I can send the delta of the code to whoever needs it.

Thanks,
Stefan

5

Installation issues / Re: web orbiter not working in web browser with LinuxMCE 1004

« on: September 18, 2012, 09:43:17 pm »

OK, I figured out what the problem was. I use a single network card in my installation. The IP address of the machine is 192.168.0.103. But the Core device has the IP address set as 192.168.1.80. This caused the following error logs in 0_web_orbiter.log:
   Attempting to create socket on host 192.168.80.1 port 3461 ... OK.
   socket_connect() failed.
   Reason: (110) Connection timed out
   Closing socket ... OK.

I updated the Core's IP address to be the same as my machine, and everything works!

6

Installation issues / Re: web orbiter not working in web browser with LinuxMCE 1004

« on: September 13, 2012, 11:56:17 pm »

Hi,

Thanks for your replies. I tried using Firefox 15.0.1 under Windows 7, Firefox 13.0.1 under Ubuntu 12.04, Safari on iPhone4 and Chrome under Windows 7. None of them work. All I get is the spinning circle and the <Home> <Back> <Refresh> <Exit> <Log out> buttons. Using the same browsers, LinuxMCE810 works OK. I set the geometry to be 4:3 as suggested by JaseP. I notice that each time I attempt to open the weborbiter, apache gives this error in /var/log/apache2/error.log:

[Thu Sep 13 17:41:39 2012] [error] [client 192.168.0.13] PHP Notice:  Undefined index: userlang in /var/www/lmce-admin/include/utils.inc.php on line 66, referer: 192.168.0.16/lmce-admin/weborbiter.php?installation=1031156&device_id=35
[Thu Sep 13 17:41:39 2012] [error] [client 192.168.0.13] PHP Notice:  Undefined index: userlang in /var/www/lmce-admin/include/utils.inc.php on line 66, referer: 192.168.0.16/lmce-admin/weborbiter.php?installation=1031156&device_id=35

Not sure if this is the cause of the problem though.

Which 1004 snapshot has this functionality confirmed to work?

Thanks,
Stefan

7

Installation issues / web orbiter not working in web browser with LinuxMCE 1004

« on: September 13, 2012, 01:17:22 pm »

Hi,

I installed the web orbiter and the proxy orbiter as per instructions by creating the devices under CORE. I can use the orbiter with the roamingorb app on the iPhone, but when accessing with a web browser, only the bottom buttons show up. I tried with both the Sept 09, 2012 and Aug 20, 2012 snapshots and same problem. It works fine with 810.

Anyone else experiencing similar issues?

Thanks,
Stefan

8

Users / Re: WAYNE-DALTON Z-WAVE® THERMOSTAT

« on: October 17, 2010, 02:19:27 pm »

Hi Everyone,

I have this thermostat installed with LinuxMCE 810. It works fine with scenarios that I created and I use it in C. The only problem is that on the Orbiters the setpoint temperature stays at 255. Everything else is fine. So for example here's how it looks:
ON/AUTO/AUTO/255 (21.0)

On the thermostat itself the setpoint is correct (i.e. as set by the scenario). So I think it's a problem with how the value is displayed or stored internally.

Anyone else experiencing the same problem?