By on in, Spark for Mac — The Best iOS Email Trinity is finally Complete It’s celebration time for us here at Beautiful Pixels. We’ve on why Spark is such an amazing app on iOS. It is the best designed, most fully featured, most fluid email client for your portable devices, and its Natural Language Search will change your life. As of today, Spark is also for your downloading pleasure. With pretty much complete feature parity, you’re getting everything the iOS app provides, including, quite splendidly, swipes. I love being able to achieve Inbox Zero nirvana with a swipe to the right.

More on this later. Also included in the Mac version is iCloud sync for your settings and accounts.

Nfn Setup For Mac Pro

You don’t need to set up all your accounts again. As proponents of Two-Factor Authentication, we cannot express enough how glad we are that this feature is a part of most modern email clients. I do have a single, small gripe though — I wish swipe worked as well as it does on iOS – A swipe in either direction brings up two customizable options for you to click on, or a long drag will perform the action you’ve mapped to the short swipe. I wish they implemented it in such a way, that a short swipe performs the short swipe action, and a long swipe performs the long swipe action. Sounds rather obvious, doesn’t it? It’s my only minor complaint in an otherwise flawless app.

Astonishingly, Spark is a free app. We honestly couldn’t believe our eyes when we saw a “Get” button next to the app’s name on the App Store. We have no hesitation whatsoever in recommending Spark to you, dear reader.

With a stunning Design, a robust Sync engine, superb NLP-based Search, a huge list of Features, and now Cross-Platform presence, Spark is finally here to replace your email app of choice. Other email apps, such as or, might have more features, or may look nicer. Nothing else out there right now gets the balance of everything as well as Spark, though.

It is one of the few apps that has the potential to assume dominance in a crowded market, and we would say this even if it wasn’t a free app on all platforms. From the Mac App Store.

The iOS app is Universal and also.

I've been looking to touchlink another remote into my existing ZLL network, but with no success. Is this even possible? My setup is a sampleremote that has touchlinked to a couple of zlights. Now I have another factory new sampleremote (all based on Lighting 1.0.1) that I would like to be a part of the existing network. Hopeful for mac. So I tried sending the touchlink RPC to the NFN sampleremote and nothing happens. Sending the touchlink to the FN sampleremote and also, nothing happens.

I am able to 'steal' a zlight with the FN remote, though. But that is not what I want, I want the FN remote to become a part of the existing network so that it can now be used to control the Zlights as well. Is this possible? If yes, how to proceed?

Any documentation pointers? Sjef, Yes this is possible, and was intentional in the spec. You need to initiate touch link on both initiators at the same time. This was hard to implement in the spec, due to the timing of the initiators being on the same channels to see each other’s Scan Req/Rsp, this is why the initiator sends 4 Scan Req on channel 11 before moving on. So when 2 remotes have their button pressed to initiate remote to remote TL it gives more time on ch11 for the remotes to see the Scn Req/Rsp.

This results in remotes being able to TL as long as they initiate the TL at around the same time, this can be difficult with remotes from different vendors if the time between button press and start of TL transaction are different. I also notice that you mentioned ' touchlink RPC', are you trying to do this over a Host interface? This could add timing variations that make this difficult to achieve. In reply to: Topcat, Thanks for your reply. Unfortunately I've not had success touchlinking the two initiators.

I tried an experiment without the RPC call as well (using a button and a LED to indicate when the TL starts). I can see a number of SCANRSP's on the FN initiator but that's all. It has not been possible to join another remote, even after trying over 50 times by pressing the buttons at the same time. Could it be that the timing requirements are much more strict than those possible to reach by hand? That kind of rules out the addition of remotes by consumers. So I think it must be something else?

Have you ever tried this scenario and did it work? Edit: It should work, it's in the Lighting Sample Application User Guide. I got it to work with both remotes as end-devices. With one or all of the remotes as a router (for host interface purposes) there's no touchlinking another remote. The question now is: Why won't it work when one of the remotes is a router? Should I add some code somewhere? Thank you, Sjef.

In reply to: Sjef, That’s correct, it is in the Sample Apps Users guide and was tested during development and validation testing. It is also in the ZLL test spec and as the sample App was the ZLL Certified should have also been tested independently by a test house. I have also tried this myself, but not sure what the exact release/pre-release version it was and it was with different HW. This is sometimes tricky on different HW platforms where the timing varies between remotes, but should not be too difficult on the same remote platform. I am sure you are aware, but make sure one remote is FN, it is not a valid usecase to do Remote to Remote TL when both remotes are NFN.

Which HW platform are you using? Can you try with the SmartRF05EB if you have not already? Can you capture a trace with the TI packet sniffer? You should be able to see the timing and if Initiator remote is on the same channel when the Scan Rsp comes. Another thing to try is varying the timing, press the FN remote button very slightly before the initiator, and visa vers. In reply to: Hi all, I am trying to setup multiple remotes in the network but I am confused by what is happening.

Nfn Setup For Mac Download

Based on the discussion above, does it mean that I have to initiate touchlink on both remotes at the same time? And one of them has to be already registered in the network and the other has to be factor new? Or I can touchlink with both remotes being factory new? In the Lighting Sample Application User's Guide (SWRU334), it says this: In order to add another Remote to the network, the new remote being brought into the network should initially be in Factory New state. Then a touchlink should be performed between the factory new and the existing Non-Factory-New (remote currently in the network) before the new remote is used in the existing network. Here is what I have tried so far. I performed touchlink on RemoteA with a Zlight.

And I can turn on and off the light. Then I have a factory new RemoteB (I presume by re-flashing it with firmware, it will be in factory new state). I brought RemoteB close to RemoteA and press the touchlink button on RemoteB but nothing happens, I don't hear a buzzer sound that indicates a successful touchlink.

However if I press the touchlink button on both RemoteA and RemoteB at the same time, both remotes will have a buzzer sound. I presume this is to indicate both remotes have been touchlinked?

But now RemoteA cannot controller the Zlight anymore. RemoteB doesn't control the Zlight too. Any help or comments? In reply to: I think I kinda got it to work, but there are still some bugs.

Nfn Setup For Macbook Pro

My previous problem has been solved partially. I have RemoteA that is already touchlinked to Zlight. RemoteB is factory new.

I pressed the touchlink button on both remotes. Now I can use RemoteB to control the Zlight (Previously this was not working maybe because of a faulty. After I change to a new this worked). But RemoteA still cannot control the Zlight. Then I have to touchlink RemoteA with the ZLight so that I can use RemoteA and RemoteB together.

Is this normal? Or after I touchlink both remotes, they both should work immediately? In reply to: For Remote to Remote TouchLink to work: Remote A should be made Non Factory New by touch linking a light (LightA). With LightA out of touchlink range (2m), hold RemoteA close to a Factory New RemoteB, press both buttons simultaneously, if both RemoteA and RemoteB start touchline scan at the same time and no other Light is in touchline range then RemoteA will pull RemoteB into the network. At the network level RemoteB will find LightA as its parent router, but at the application level it will have no knowledge of any Lights and will not be able to control them. At this point RemoteA can still control LightA, RemoteB is on the network but can not control LightA.

To get RemoteB to control LightA 1 of 2 things need to happen: 1. RemoteB Touchlink LightA to add it to the target list and control it. If RemoteB is on the same network as LightA the light will identify and RemoteB will add it to the target list, the light will remain on the network and still be controllable from the other Remote previously touch linked. Use remote cloning to transfer all target (Light) info from RemoteA to RemoteB, the TI ZLL SDK supports this but it is not included in the remote sample application. You will need to use a combination of TI documentation and ZLL Spec to implement this correctly using the touchlink Utility commands supported in the ZStck-Lighting SDK. However there are a number of scenarios that could happen to make Remote-to-Remote touchlink not work as expect.

The Light is in touchlink range when touch linking the remote. RemoteB my touchlink the Light and steel it to create a new network, LightA will blink to identify during touchlink, remoteB will have control over the Light and RemoteA will no longer be able to control the Light. RemoteA and RemoteB touchlink Scans are not aligned. To help Remote to Remote TL the spec mandates 5 scan reqs on ch11 to make more chance of remotes that start remote-to-remote TL at the same time find each other. However if not aligned then 1 remote may move to another scan channel and miss the other remote, and TL will fail. If TL fails and RemoteB is still Factory New when you touchlink LightA, then LightA will be stolen, RemoteB will control it, but RemoteA will no longer have control. RemoteA and RemoteB are Factory New, or RemoteA and RemoteB are Non Factory New.

This is mandated to fail by the spec. RemoteB is Factory New and RemoteA is None Factory New, but RemoteA is part of a HA network. This is mandated to fail by the spec. All content and materials on this site are provided 'as is'. TI and its respective suppliers and providers of content make no representations about the suitability of these materials for any purpose and disclaim all warranties and conditions with regard to these materials, including but not limited to all implied warranties and conditions of merchantability, fitness for a particular purpose, title and non-infringement of any third party intellectual property right.

No license, either express or implied, by estoppel or otherwise, is granted by TI. Use of the information on this site may require a license from a third party, or a license from TI. Content on this site may contain or be subject to specific guidelines or limitations on use. All postings and use of the content on this site are subject to the of the site; third parties using this content agree to abide by any limitations or guidelines and to comply with the of this site. TI, its suppliers and providers of content reserve the right to make corrections, deletions, modifications, enhancements, improvements and other changes to the content and materials, its products, programs and services at any time or to move or discontinue any content, products, programs, or services without notice.