WiRe is a server/client system for controlling redstone output. It is focused on controlling doors, hatches, bridges, barriers, etc (e.g. pistons, MFFS mod, Light Bridges and Doors mod) but can control anything that operates on a redstone signal (e.g. redstone lights, machines, etc.). The server is the 'control center', capable of managing up to 20 clients (per server) all from a touchscreen monitor. Each client controls one door/hatch/etc. and reports its status to the server wirelessly or via wired network.
Please note:WiRe is NOT compatible with ComputerCraft 1.74 or ComputerCraftEdu 1.74 or the combined CC/CCEdu 1.74 jar. This includes modpacks that use these versions [e.g. Tekkit Legends]
WiRe Server monitor (control center)
- Each server manages a single 'network' of clients (network group/color is selected during setup). This allows you to have one server control public doors, while another controls private doors, another controls bridges, etc. Due to monitor array size limitations (8 monitors wide), each server should be limited to 20 clients.
- Any client can be opened/closed/activated/deactivated, locked and unlocked from the server.
- Any client that is locked will not operate until it is unlocked at the server (wood/iron doors, although locked, will still open with a redstone signal - there is no way around this).
- The server can also lock or unlock all clients simultaneously with a single touch.
- Clients can support multiple monitors, allowing door/hatch/etc. control from both sides.
- Pressing 'F1' in the client or server terminal screen will display basic help
- Pressing 'q' in the client or server terminal screen will gracefully exit the client or server
This was inspired by a system I made quite awhile ago for a base I had in FTB Ultimate. I was new to Lua then and the system was quite buggy and temperamental...it also was 'mission specific' - trying to use the system in another base wasn't worth the trouble. I've wanted that level of control in my newer bases so I decided to revisit the idea, and WiRe is the result.
WiRe is designed to be relatively flexible - to achieve that, the client asks about 8 questions during setup (the server asks 4). It goes pretty quick after you've been through it once, though.
Take note: as of version 2.0.00 WiRe encrypts all its communications using SquidDev's AES and Alex Kloss' base64.
- For best performance mix computers with even and odd numbered IDs on each network to distribute the load on the server(s) (this makes a difference)
I hope people find this as useful as I have. Go WiRe up your base and let me know what you think!
Screenshots
WiRe Server terminal screen
WiRe Client terminal screen
Example WiRe Server hardware setup (wireless modem on back in this example, but it can be placed on any side)
Example WiRe Client hardware setup (wireless modem on back in this example, but it can be placed on any side)
Requirements
- WiRe requires ComputerCraft 1.63 or newer
- WiRe clients require a WiRe server; make sure your server is up and running before installing your clients
WiRe Server:
- Standard or advanced computer with at least one modem (wired or wireless) and a monitor array consisting of one to eight advanced monitors
- The monitor array will serve as the main control center for monitoring and managing doors/hatches/etc. - the array may be attached to the server directly or via modem/network cable
- Wired modems on the server must be turned on to work as communication devices, but they don't need to be turned on if you are only attaching to monitors (the monitors' modems *do* have to be turned on, though)
- The server will detect and handle multiple modems (including mixing wired and wireless), but will only 'open' wired modems for communication if another computer is attached via network cable (and its modem is also turned on)
- If you add clients via wired modem after WiRe server is already running, you will have to restart the server if no clients were attached via that modem when the server was originally started
WiRe Client:
- A server up and running for the network group the client will be joining
- Standard or advanced computer with a modem (wired or wireless) and one or more optional advanced monitors (for local door control) - or a wireless turtle (no monitors)
- WiRe client is designed to use only 1 modem - it will use the *last* modem it finds - if you want to use a wired network use only wired modems and only one per client. Wired modems need to be turned on. Clients will not be able to get a GPS fix on wired networks.
- The optional advanced monitors will serve as 'touch screens' to operate the door locally - they may be attached to the client directly or via modem/network cable
Want to use pocket computers with WiRe?
cc10 and WiRe can work together to provide limited functionality. Follow these directions and you should be good to go...
- Install cc10 Host and WiRe Client on the same computer (not portable).
- Name cc10 Host as 'cc10host'
- Name WiRe Client as 'WiReClient'
- Configure both of them to use the same side for redstone output.
- Configure cc10 Host with a password if you would like a small layer of protection (passwords and communications are not encrypted).
- Create a file named 'startup' with the following code
shell.run("cc10host WiReClient")
Reboot the machine and the startup file will launch cc10 Host in daemon mode, which will then launch WiRe Client automatically.
- Note that cc10 is not 'aware' of the WiRe 'lock' state, so it will essentially bypass WiRe and operate devices regardless of their lock status.
- Open/closed/on/off status are reported accurately in both cc10 and WiRe.
- Now you can use WiRe server *or* a portable computer (with cc10 remote installed) to control your WiRe clients.
- WiRe server released at 1.0.00
- WiRe client released at 1.0.00
5-21-14
- WiRe server updated to 1.0.01 - minor tweaks and changes, added info to help screen
- WiRe client updated to 1.0.01 - minor tweaks and changes, added info to help screen
5-22-14
- WiRe server updated to 1.0.02 - user can now choose not to get a GPS fix on startup (during first-time setup)
- WiRe client updated to 1.0.02 - user can now choose not to get a GPS fix on startup (during first-time setup)
- WiRe server updated to 1.0.03 - changed how hosting is implemented to better utilize the new rednet.host feature (this requires updating the server and client), minor tweaks and changes
- WiRe client updated to 1.0.03 - changed how hosting is implemented to better utilize the new rednet.host feature (this requires updating the server and client), minor tweaks and changes, fixed an issue where success state would report as false if the device was locked when queried
5-23-14
- WiRe server updated to 1.0.04 - reduced frequency of monitor writes
- WiRe client updated to 1.0.04 - reduced frequency of monitor writes, location now displayed on terminal screen
- WiRe server updated to 1.0.05 - server no longer looks for key/char inputs if running in daemon mode
- WiRe client updated to 1.0.05 - client no longer looks for key/char inputs if running in daemon mode
- WiRe server updated to 1.0.06 - optimized terminal screen writes - now only 'updated' text gets redrawn; with an exception for the client list which still updates regularly
- WiRe client updated to 1.0.06 - optimized terminal screen writes - now only 'updated' text gets redrawn, minor reformatting of terminal output
- WiRe server updated to 1.0.07 - small tweak to charInput(), minor tweaks and updates
- WiRe client updated to 1.0.07 - small tweak to charInput(), fixed a mistake in file handing during init, fixed a case when answering queries that could confound the client and cause it to report incorrect information
5-25-14
- WiRe server updated to 1.0.08 - fixed a logic derp regarding whether or not to get a GPS fix
- WiRe client updated to 1.0.08 - fixed a logic derp regarding whether or not to get a GPS fix
5-26-14
- WiRe server updated to 1.0.09 - fixed a condition when a client is gracefully exited that would cause the server monitor to be updated incorrectly resulting in the last entry being displayed twice
- WiRe client updated to 1.0.09 - minor code cleanup and fixes
- WiRe server updated to 1.0.10 - changes to help screen, fixed several issues where monitor calls were using terminal colors, fixed an issue with text formatting on the terminal screen
- WiRe client updated to 1.0.10 - changes to help screen
5-28-14
- WiRe server updated to 1.0.11 - optimized 'All Device Lock/Unlock' handling
- WiRe client updated to 1.0.11 - fixed an error in status reporting if the device's default 'Lock' status is 'OFF'
5-29-14
- WiRe server updated to 1.0.12 - eliminated unnecessary monitor writes
- WiRe client promoted to 1.0.12 - no changes
June
6-8-14
- WiRe server updated to 1.0.13 - added differentiation between doors and pistons (doors now behave properly), minor tweaks and fixes
- WiRe client updated to 1.0.13 - added differentiation between doors and pistons (doors now behave properly), minor tweaks and fixes
6-13-14
- WiRe server updated to 1.0.14 - added wired modem support for communications
- WiRe client updated to 1.0.14 - added wired modem support for communications
6-14-14
- WiRe server updated to 1.0.15 - updated help screen, fixed a condition that could result in a blank control monitor when a client was gracefully exited
- WiRe client updated to 1.0.15 - updated help screen
- WiRe server updated to 1.0.16 - server now looks for a modem *before* initializing first-time setup
- WiRe client updated to 1.0.16 - client now looks for a modem *before* initializing first-time setup
- WiRe server updated to 1.0.17 - displayed names are now split semi-intelligently - no more need to 'space out' names
- WiRe client promoted to 1.0.17 - no changes
6-15-14
- WiRe server updated to 1.0.18 - fixed a condition when a client is gracefully exited that would cause the server terminal screen to be updated incorrectly resulting in the last entry being displayed twice
- WiRe client updated to 1.0.18 - fixed a text formatting issue that left stray characters onscreen after a state change from LOCKED to OFF or ON
6-17-14
- WiRe server updated to 1.0.19 - fixed a bug in device name splitting routine that could crash the server
- WiRe client promoted to 1.0.19 - no changes
July
7-10-14
- WiRe server updated to 1.0.20 - fixed a display bug that could cause the server to crash in certain circumstances, minor code cleanup
- WiRe client updated to 1.0.20 - several minor tweaks and fixes
September
9-7-14
- WiRe server updated to 1.0.21 - reworked polling to reduce computing expense and rednet pressure
- WiRe client updated to 1.0.21 - reworked polling to reduce computing expense and rednet pressure
9-11-14
- WiRe server updated to 1.0.22 - optimizations to polling, minor tweaks and fixes
- WiRe client updated to 1.0.22 - minor tweaks
9-12-14
- WiRe server updated to 1.0.23 - fixed a couple of derpy bugs in first-time setup
- WiRe client updated to 1.0.23 - small tweak to first-time setup
October
10-11-14
- WiRe server updated to 1.0.24 - several optimizations to netSend() function, fixed a flaw in modem counting logic
- WiRe client promoted to 1.0.24 - no changes
2015
February
2-22-15
- WiRe server updated to 1.0.25 - several tweaks and fixes, code cleanup
- WiRe client updated to 1.0.25 - several tweaks and fixes, code cleanup
March
3-5-15
- WiRe server updated to 1.0.26 - minor tweak and code cleanup
- WiRe client updated 1.0.26 - minor tweak and code cleanup, added feature for clients to start up in last state (on/off/open/closed) as opposed to a 'default' startup state. Clients will have to go through first-time setup again to take advantage of the new feature (delete "/data/WiReClientCfg" and rerun the program to initiate first time setup again). Also default lock and default unlock states have been removed - locking now just locks the device in whatever state it is in instead of forcing a state change.
- WiRe server updated to 1.0.27 - code cleanup/optimization
- WiRe client updated to 1.0.27 - several bug fixes related to new 'last state resume' feature, default lock/unlock state removed (devices are now locked/unlocked in whatever state they are already in)
3-17-15
- WiRe server updated to 1.0.28 - fixed dropped client detection, code cleanup/optimization
- WiRe client updated to 1.0.28 - code cleanup/optimization
May
5-24-15
- WiRe server updated to 1.0.29 - code optimization
- WiRe client updated to 1.0.29 - code optimization
September
9-25-15
- WiRe server updated to 1.1.00 - major code optimization - this is a highly recommended update
- WiRe client updated to 1.1.00 - major code optimization - this is a highly recommended update
2016
June
6-1-16
- WiRe server updated to 1.5.00 - bug fixes, major code optimization, communications should be much more reliable in noisy environments
- WiRe client updated to 1.5.00 - bug fixes, major code optimization, communications should be much more reliable in noisy environments
July
7-11-16
- WiRe server updated to 1.5.01 - added sanity check to name splitting function (bug fix)
- WiRe client updated to 1.5.01 - fixed typo in first-time setup routine (bug fix)
2017
February
2-27-17
- WiRe server updated to 2.0.00 - added communications encryption (SquidDev's AES and Alex Kloss' base64), increased polling interval
- WiRe client updated to 2.0.00 - added communications encryption (SquidDev's AES and Alex Kloss' base64)
August
8-16-17
- WiRe server updated to 2.0.01 - lock state handled separately from switch state
- WiRe client updated to 2.0.01 - lock state handled separately from switch state
September
9-10-17
- WiRe server updated to 2.0.02 - now works with Lua 5.1 features disabled
- WiRe client updated to 2.0.02 - now works with Lua 5.1 features disabled
November
11-23-17
- WiRe server updated to 2.0.03 - code cleanup/optimization, server poll timing adjusted, now more tolerant when hosting a full list (18-20 clients), clients shouldn't mysteriously drop any longer
- WiRe client updated to 2.0.03 - code cleanup/optimization, client report timing adjusted, clients shouldn't mysteriously drop any longer when the server has a full list (18-20 clients)
December
12-20-17
- WiRe server updated to 2.0.04 - code cleanup/optimization, client polling eliminated - clients will no longer drop off the list unless gracefully exited at the client
- WiRe client updated to 2.0.04 - code cleanup/optimization
2018
August
8-26-18
- WiRe server updated to 2.0.05 - fixed device sorting, client polling reworked and reintroduced - clients that 'drop' without being gracefully exited will be named in yellow instead of being removed from the list
- WiRe client updated to 2.0.05 - minor tweak to poll timing, terminal screen now indicates when the client successfully updates the server and when it doesn't
As always, my sincere thanks to everyone who made this possible; with special thanks to the following:
- SquidDev for his AES encryption/decryption function
- Alex Kloss for his base64 encoding/decoding function
Location[string "FindMe"]:23143: bad argument #1 to 'returnPos' (vector expected, got nil)
Posted 22 May 2014 - 06:23 PM
Well, I was going to make this.
Oh well, you did better on this then I could've ever done. GJ.
PS: Maybe allowing you to control the server through a PDA?
This is awesome! but maybe add a way to connect network monitors to a cliënt? (if that is possible)
Thanks, Dry_Taste. If you mean connect monitors via modem/network cable - that is already possible If that's not what you mean, would you please clarify a bit?
Agent Silence, on 22 May 2014 - 06:23 PM, said:
Well, I was going to make this.
Oh well, you did better on this then I could've ever done. GJ.
PS: Maybe allowing you to control the server through a PDA?
Thank you, Agent Silence. I've been considering adding PDA support. Unfortunately, due to how WiRe works, it won't be easy to add (I wish I had thought about PDA support earlier in the project). That's not to say I won't get around to it; but if I do, it'll probably take awhile to get it where I'm happy with it - no promises, though, as I may not be able to implement it in a way I'm happy with. I don't know if it would interest you, but I also have a program for portable computers called cc10. It allows you to control redstone wirelessly as well, but with a slightly different feature set.
This is awesome! but maybe add a way to connect network monitors to a cliënt? (if that is possible)
Thanks, Dry_Taste. If you mean connect monitors via modem/network cable - that is already possible If that's not what you mean, would you please clarify a bit?
Thanks for the reply, i wasn't aware of that (i tried to do that but i obviously did it wrong) how do i do this? I tried to connect a wire-modem to a client but it doesn't show anything on the monitor.
Edit: Nevermind forgot to activate the modems on the terminal and monitor, i'm sorry ^^''
@bbilko - are you running this with ComputerCraft 1.6 or an earlier version (e.g. 1.58)? Based on the error and the line number it looks like you aren't running ComputerCraft 1.6 which WiRe requires.
Done - wired modem support for communications is added. That's actually something I've been planning on adding for awhile - not sure why I didn't do it sooner. Download 1.0.14 (client and server) to get the updated functionality.
Due to the fact that it was at 1:00 in the morning, I forgot to put a wireless modem on the computer *derp*. Could you consider putting a check for a modem as the first thing (not the last) the program does? Other than that, great program! Also, may I ask you how you got the server monitor to print the clients like that with the touch screen?
I'm guessing you mean the order in which the checks are made during first time setup? If so, that makes a lot of sense - I'll take a look at that and make it right.
As for how I got the names to display, it's not an elegant solution, but here's what I do...
- Each name can be 12 characters
- Each name is 'broken in half' and displayed 6 characters per line (2 lines)
- Just add spaces in the name to space it out so it looks right on the monitor
Like I said, not elegant...but it works - and I haven't yet conquered the coding to have the program do it automatically.
@micmou - you're not the first to suggest it. I've considered it, but it wouldn't be an easy project - WiRe wasn't designed with that in mind. It's still a possibility, but it'll probably happen later rather than sooner. Although the feature set is a bit different, you may want to check out my cc10 program - it allows you to wirelessly control redstone (even analog redstone) outputs with an advanced wireless pocket computer.
@Dog I would suggest storing the names in a table and using 'table.sort' and some sort of string manipulation (string.format?) to sort them automatically. Also, how did you have the on/off switches work (respond to touch) when the program doesn't know how many clients there will be? In other words, how does the program auto. set the coords. for each of the buttons?
@cmckain14 - thanks for the suggestions The difficulty (for me) is looking at a string with multiple spaces and determining whether to break the string at the first space, second space, etc. The 'work' that needs to be done still eludes my understanding atm. I've only used (and am only familiar with) a few string api calls - guess it's time to sit down and read up a bit. I would definitely like to make the switch labeling 'work better'.
Actually, the server knows how many clients it has at any one time by counting the number of entries in the table of clients (#allClients). In this case, each element on the monitor is a static 6 characters wide, with the first starting at space 2. The formula I used for placement is...
(<number of current client>*8)-6
Although I could have just as easily used a 'for loop' starting at 2 and incrementing by 8 for positioning, inside another loop for incrementing client #.
To match the touch to the client, I compare the x touch coords using a variation of the above formula, in a loop, to find the client number.
for i = 1,#allClients,1 do --# loop through the client list
if posX >= (i * 8) - 6 and posX <= (i * 8) then --# if our touch x position describes the x position of a button
client = allClients[i].cc --# set 'client' to the computer ID# belonging to table entry 'i' in allClients
Y coords are checked differently since they are static and the same for all buttons.
I hope that explains it. If I misunderstood, or you'd like further clarification, please let me know
EDIT: I also released an update to WiRe server and WiRe client - they now look for a modem before starting first-time setup and warn you at the beginning if none is detected. My apologies for missing something so obvious.
EDIT2: Another update for WiRe server - the server now semi-intelligently splits client names on the monitor control display (no more need to 'space out' names). It looks for a single <space> and if it finds one, and both 'halves' of the name are 6 characters or less, it uses the 'split' name, otherwise it just splits the name at the 6 character mark and shows them as 6 characters & 6 characters.