Did you check with the manufacturer?
Emailed a while ago, waiting to hear back.
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.
Did you check with the manufacturer?
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
*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?
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.
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.
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
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
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
The tasks could be picked by the community every two weeks for most important focus.
More stable releases
Targeted feature completion.
Easier update paths
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.
2014-10-13 12:15:41.262 Info, Node006, Sending (Poll) message (Callback ID=0x13, Expected Reply=0x04) - SwitchMultilevelCmd_Get (Node=6): 0x01, 0x09, 0x00, 0x13, 0x06, 036 10/13/14 12:15:41.287 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:15:46.317 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:15:51.349 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:16:01.389 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:16:06.420 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:16:11.451 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:16:16.481 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
36 10/13/14 12:16:21.625 ZWInterface::OnNotification() : unhandled/ignored notification = 3 <0xb63ffb40>
x02, 0x26, 0x02, 0x25, 0x13, 0xf3