1220 posts
Earth orbit
Posted 21 May 2014 - 01:20 AM
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)
[attachment=1657:WiRe Server Mon.png]
- 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!
[attachment=1658:WiRe Server Term.png]
WiRe Client terminal screen
[attachment=1728:WiRe Client Term.png]
Example WiRe Server hardware setup (wireless modem on back in this example, but it can be placed on any side)
[attachment=2616:WiRe Server Setup.jpg]
Example WiRe Client hardware setup (wireless modem on back in this example, but it can be placed on any side)
[attachment=2624:WiRe Door Setup.jpg]
- WiRe clients require a WiRe server; make sure your server is up and running before installing your clients
WiRe Server:
WiRe Client:
WiRe Client:
cc10 Thread for those wanting pocket computer support
Similar programs:
WirelessControl by unobtanium
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
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)
[attachment=1657:WiRe Server Mon.png]
- 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!
Spoiler
WiRe Server terminal screen[attachment=1658:WiRe Server Term.png]
WiRe Client terminal screen
[attachment=1728:WiRe Client Term.png]
Example WiRe Server hardware setup (wireless modem on back in this example, but it can be placed on any side)
[attachment=2616:WiRe Server Setup.jpg]
Example WiRe Client hardware setup (wireless modem on back in this example, but it can be placed on any side)
[attachment=2624:WiRe Door Setup.jpg]
Spoiler
- 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
Spoiler
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.
Spoiler
WiRe Server:
Paste: hqpRw4Jy
ComputerCraft: pastebin get hqpRw4Jy startup
WiRe Client:
Paste: jtFa7V1n
ComputerCraft: pastebin get jtFa7V1n startup
cc10 Thread for those wanting pocket computer support
Spoiler
Spoiler
Spoiler
5-20-14
- WiRe server released at 1.0.00
- WiRe client released at 1.0.00
- 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
- 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
- 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
- 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
- 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
- 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'
- WiRe server updated to 1.0.12 - eliminated unnecessary monitor writes
- WiRe client promoted to 1.0.12 - no changes
Spoiler
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
- 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
- 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
- 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
- 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
Spoiler
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
Spoiler
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
- WiRe server updated to 1.0.22 - optimizations to polling, minor tweaks and fixes
- WiRe client updated to 1.0.22 - minor tweaks
- 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
Spoiler
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
Spoiler
Spoiler
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
Spoiler
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)
- WiRe server updated to 1.0.28 - fixed dropped client detection, code cleanup/optimization
- WiRe client updated to 1.0.28 - code cleanup/optimization
Spoiler
5-24-15
- WiRe server updated to 1.0.29 - code optimization
- WiRe client updated to 1.0.29 - code optimization
Spoiler
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
Spoiler
Spoiler
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
Spoiler
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)
Spoiler
Spoiler
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)
Spoiler
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
Spoiler
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
Spoiler
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)
Spoiler
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
Spoiler
Spoiler
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
Similar programs:
WirelessControl by unobtanium
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
Edited on 26 August 2018 - 07:26 PM
