Ok, "How would you do this?" is a considerably big question (sometimes its simplier to make a program than explain how to do it for someone other), but I'll try to provide you with some usefull tips about what you can make to implement your application. Nearby all suggestions made by me earlier can be used for this, excluding, may be, remote panels, as you plan to use wireless LAN and remote LV panels usually consume bandwidth significally, so this is not a solution.
Anyway, you need two kind of vi's on your remote computer. First - the most simple class - are the vi's to set/get parametrs, like setting/getting lights state. Here you can go on with solution you alredy implement - your vi server/client. So you call such a vi from your laptop, its sets or gets parameter and returns its value to your application.
Second part - your acqusition vi - is more tricky and there is a number of ways to implement it. The problem you have here is similar with passing data in and out of a running while loop. The approaches to solve it are not the same, but similar in both cases - is this loop runs on the same computer or on a remote one.
1) you can use global variables, preferably so called "old style" globals to pass the data. With them you work with the same approach as with earlier mentioned vi's. Like this you can set the filename (and may be some other initial parameters) to store acquired data on remote computer.
2) you can use queue's or notifiers mechanism to do the same job. It's great when loops are running on the same computer, and, personnaly, I prefer this one, but for remote you need the remote implementation of this approach - it's available somewhere on the OpenG as I've mentioned before.
3) Finally, DataSocket server. I'm not very familar with DS, but it's looks like it is a natural and not a diffucult thing to use.
So, I consider that you make your acquisition vi - with some kind of a while loop inside.
If you prefer to use data transfer by variables, then, before launching it you supply initial parameters of your acquisition by mean of setting some "old-style" globals on your remote PC. As a global variable you can implement also your "stop acquisition" button, so remote acquisition vi will check it on each iteration. Also in a remote acquisition while loop you set the variable with the last acquired data - so you can read it with your laptop if you need (as I understand, you monitor your remote system with laptop, so you don't need ALL data to be read immediately - only to know that it is working "down there". The remote system stores all the data in a file, so you can implement lately a vi that reads and sends this file to your laptop).
Also, you can use the "remote queues" instead of variables. Good sides are that you can implement more sofisticated command interface for your remote system and it is also can be used for syncronisation purposes. Like this you can implement a "command" queue for your remote acqusition, so on each iteration you test (but not wait) - is there any new commands in this command queue (i.e. "stop", or, suppose, "change acqusition parameter") - and react accordingly. If there is no new commands, you measure new data and repeat the procedure. Like this you can implement the output queue for your data to be passed to the laptop or use a global variable.
Ok, If you have questions concerning details of the approaches described here - feel free to post here, and I'll try to supply more information.
Anyway, If you are not very familar with labview programming than I recommend BEFORE trying to build your application look for examples given with LV distribution disk, then may be try to implemet some - or all - of the mentioned approaches.
PS: here just some thoughts about the acqusition vi you supplied as an example. Here I'll try to explain why this is not at all a good example of coding.
You have two parrallel while loops running there, one to acquire data, and the other to save it. The data a passed between them by a local variable. The problem is that your loops are not at all syncronised, so one can not be sure:
1) are you save data that have been already saved (if you save data faster than you acquire it)
2) are you loose data (aquisition if faster then you save the data)
3) what will be in the case that you write in this variable the same time you read it?
In other words, we can have here the classic "run condition". You cannot be sure what is passing there in reality.
To be sure that all data you acquire will be save (and without duplicates) the queue syncronisation are much more preferrable.
Sorry for my poor english
