Radio Thermostat 3M-50 Wifi support

Plugins & Plugin Development General Plugin Discussion
41

Ok, sounds like something got really goofed up. That user interface has not been part of the plugin since the early alpha version. Both 0.8 and 1.0 have the new user interface, and I’ve double checked to make sure apps.mios.com has the correct files. (shown here:
MiOS Apps )

I’m guessing there’s a bug in apps.mios.com that’s messed up the distribution of the new version. I’m putting a ticket in with MCV and hopefully they’ll get on it ASAP.

If you don’t mind losing your settings, it may be worth while uninstalling and reinstalling the plugin to see if you get a correct distribution of 1.0 installed.

Sorry for the inconvenience!

Hugh

42

i didn’t do an uninstall yet but i did download the new version files manually - didn’t help at all although I can now toggle “LooseTempControl”

m

43

I believe my plugin still shows version 0.4. Isn’t the plugin suppose to automatically update?

John

44

Also, is there any way to pass the sate of the device to Vera? (ie, is the air actually running?)

45

[quote=“jwiz, post:43, topic:170555”]I believe my plugin still shows version 0.4. Isn’t the plugin suppose to automatically update?

John[/quote]

Yep, they’re supposed to:

http://forum.micasaverde.com/index.php/topic,9289.0.html

Not sure how to force it to upgrade other than uninstall / reinstall. (and I’ve just double checked again that a clean install of the latest version from apps.mios.com results in a fully working and up to date version.)

46

Uninstalled and reinstalled - all better now

47

The state does get passed to Vera, but it’s not displayed in the UI. I want to provide a visual with an icon that changes to show the current state, but unfortunately, it’s not possible in the current version of UI5. I’d thought about displaying it in a text field - maybe I should do that even though it would be ugly. :slight_smile:

If you want to access the current state programatically (in a scene, for example), you can access the state like this: (replace 99 with the device number for your thermostat)

[tt]
local operatingState = luup.variable_get(“urn:micasaverde-com:serviceId:HVAC_OperatingState1”,“ModeState”, 99) or “”
local fanStatus = luup.variable_get(“urn:upnp-org:serviceId:HVAC_FanOperatingMode1”,“FanStatus”, 99) or “”
if (operatingState == “Idle”) then
– do something here if the thermostat is idle
elseif (operatingState == “Heating”) then
– do something here if the thermostat is currently heating
end
if (fanState == “On”) then
– do something if the fan is currently running
end
[/tt]

Possible values for the operating state are:

        <allowedValue>Idle</allowedValue>
        <allowedValue>Heating</allowedValue>
        <allowedValue>Cooling</allowedValue>
        <allowedValue>FanOnly</allowedValue>
        <allowedValue>PendingHeat</allowedValue>
        <allowedValue>PendingCool</allowedValue>
        <allowedValue>Vent</allowedValue>

The fan is either “On” or “Off”.

48

Good. I still haven’t heard anything back from MCV. :frowning:

49

Any way to use your GUI with the Zwave version of this stat?

m

50

[quote=“resq93, post:49, topic:170555”]Any way to use your GUI with the Zwave version of this stat?

m[/quote]

Nope, unfortunately, with the Z-wave version, you’re stuck with more basic functionality. There is no standard way to control “temperature hold” in the UPnP spec, which is probably why MCV decided not to implement it.

51

WAIT!!! Now that I reinstalled I see your GUI for the zwave stats as well! The setting tab for those devices is correct too - do you think the hold button will work?

M

52

[quote=“resq93, post:51, topic:170555”]WAIT!!! Now that I reinstalled I see your GUI for the zwave stats as well! The setting tab for those devices is correct too - do you think the hold button will work?

M[/quote]

That actually sounds like a serious bug in Vera if you’re seeing my GUI with the Z-wave devices. There’s no way it would actually work as the underlying z-wave devices just don’t support the hold functionality through the API…

Would you mind sending me a screenshot so I can report it to MCV as a bug? (I don’t have any Z-wave thermostats to try it with)

53

So what seems to have happened is that I had your plugin running for a few days, I then added some zwave stats which reverted me back to their GUI (i never actually got your upgrade) When I re-installed after having both types it applied your GUI to all.

I will PM the screen shots

54

[quote=“resq93, post:53, topic:170555”]So what seems to have happened is that I had your plugin running for a few days, I then added some zwave stats which reverted me back to their GUI (i never actually got your upgrade) When I re-installed after having both types it applied your GUI to all.

I will PM the screen shots[/quote]

Thanks for the screenshot, I’m not sure MCV would have believed it until they saw it. :slight_smile: It’s helpful that the z-wave stats have their extra buttons inactive as that makes it even more obvious that there’s a problem.

55

MiOS associates one Json per device type. So if you have two devices, defined in two separate device files, each with its own Json, but the same device type, then both devices will have the same UI, and that will be the UI from the last loaded Json.

In this case both your custom thermostat and the Z-Wave thermostat have the same device type, but each has its own Json. So the UI of both thermostats are the same. The first loaded Json is discarded, which in this case it’s the one from your plugin. (Actually it’s not excluded that both Jsons could be mixed and the end result is a mishmash of controls from both Jsons).

The solution is to change the device type of your thermostat both in the device file and in the Json file (at the bottom of the file).

56

[quote=“mcvflorin, post:55, topic:170555”]MiOS associates one Json per device type. So if you have two devices, defined in two separate device files, each with its own Json, but the same device type, then both devices will have the same UI, and that will be the UI from the last loaded Json.

In this case both your custom thermostat and the Z-Wave thermostat have the same device type, but each has its own Json. So the UI of both thermostats are the same. The first loaded Json is discarded, which in this case it’s the one from your plugin. (Actually it’s not excluded that both Jsons could be mixed and the end result is a mishmash of controls from both Jsons).

The solution is to change the device type of your thermostat both in the device file and in the Json file (at the bottom of the file).[/quote]

@mcvflorin,

Thanks for chiming in. The definitive answer is always much appreciated. :slight_smile:

Do you know if most of the user interfaces (Vera, Android, iOS) use DEVICE_CATEGORY_HVAC to identify the device as a thermostat, or do thney look for the “urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1” device type?

If they use category, is there a way to get the device categorized as a thermostat if I change the device type to something other than “urn:schemas-upnp-org:device:HVAC_ZoneThermostat:1” ?

Otherwise, it sounds like I’ll have to drop support for the additional thermostat capabilities in the Vera UI.

Thanks,
Hugh

57

I don’t know what they are using, maybe @garrettwp or @automator.app can chime in and answer this question.

Yes, there are 2 ways to place a device in a certain category:

  1. The “official” way is by using the <Category_Num> tag in the device file, e.g.
<Category_Num>5</Category_Num>

The drawback of this method is that this tag was added recently, in 1.5.346 IIRC, so it won’t work on older firmwares or on UI4.

  1. Using Lua code in the plugin’s startup function.
luup.attr_set("category_num", "5", lul_device)

lul_device is the device number parameter which is passed to the startup function. This method works on UI2+ firmwares.

58

Currently AutHomation for android uses device categories to try it’s best to figure out the device as this is the only information I have via lu_sdata. As long as the thermostat plugin is in this category and uses the thermostat service types, it should work in my app. In future versions of UI5 (1.5.372 and newer) MCV has added an api to allow me to get the device type of the device and still maintain the small file size of lu_sdata. I will be adding this into a future build of AutHomation (2.1).

As for other apps, it is hard to say what they use. But many of them use the user_data and I would assume that they go by the device type. Hopefully others can chime in.

  • Garrett
59

The is also a bug open for the behavior that Florin describes above. I don’t believe it should be that way, but more that’s because someone implemented it that way.

60

@guessed

It’s not a bug, it’s this way by design, since UI1.