Jekyll2025-05-14T10:48:28-04:00http://www.joshlebo.com/feed.xmljoshlebo.comAdventures in computing, electronics, making, and modifying of things. Garage Door Control with an ESP32, Tasmota, and SmartThings2024-01-12T07:00:00-05:002024-01-12T07:00:00-05:00http://www.joshlebo.com/making/2024/01/12/esp32garagedoorThis is a work in progress
Proceed with caution.
I am not responsible for the destruction of property or wildlife. Use sound judgement.
Newer Liftmaster garage door openers have MyQ cloud support. It’s possible to use a phone app with the legacy Internet gateway (828LM) to operate the door, but tying that cloud to Samsung SmartThings didn’t seem straightforward. Decided to build my own solution and link to a SmartThings gateway with Matter over local wifi. This howto would probably work with Amazon Alexa or Google Nest with a few modifications.
The overall goal was to have my garage door controller communicate with a local SmartThings hub, and leverage that existing cloud connection to provide app functionality.
The goal is for this build is twofold: report the garage door state, and provide a means to change that state. These two functions will be independent, but are able to be viewed or changed via the SmartThings phone app. Routines can be written to automate as desired, for example “If garage door is open after 11:00pm, close garage door”
An ESP32 running Tasmota communicates with the SmartThings hub, and reports whether the reed switch is open or closed. If a change in the door state is requested, the ESP32 fires a relay to simulate a button press to initiate door action.
Most older garage door openers have a set of contacts that if closed, trigger action on the garage door. On some newer ‘secure’ garage doors, only a signal from a wall panel or wireless remote can trigger door action. In this howto, my relay will be connected to a wireless remote, but know that it could be wired directly to contacts on an older model.
The SmartThings hub is leveraged to send notifications and automate routines.
Items Required
Items Required:
ESP32 microcontroller - I use a 38 pin ESP-WROOM-32 dev board with pin headers - $4
Prices are rounded up, if you have bins of components like I do, you may have some of the above laying around.
ESP32 Config
Find yourself an ESP32 microcontroller on a dev board, and get it programmed with Tasmota https://tasmota.github.io/. Keep in mind that you need an ESP32, as an ESP8266 is not supported at the time of this article. The web browser based installer works great for an initial flash. I’m using Tasmota 13.3 in the examples.
In Tasmota, browse to Configuration -> Configure Module. Set GPIO18 as Relay 1, and GPIO19 as Switch 2. The pins and values used do not matter as long as you keep track of the values used. Save your config and jot them down!
From the Main Menu again, go to Consoles -> Console. Run the following commands:
SetOption114 1
PulseTime1 5
SwitchMode2 2
Option114 decouples Relays from Switches, as we will have two separate devices (a reed sensor and an independent switch). PulseTime is the duration to toggle the relay, and SwitchMode sets switch2 to inverted follow mode (0 = ON, 1 = OFF)
Tasmota has a ton of config outside of the scope of the howto, but I often set the following:
SO53 1 = show hostname and IP
SO146 1 = Display internal temp
SO08 1 = Temp in F not C
... and many others
I purchased a garage door opener clone and paired it with my opener. One difference I found with this opener is that instead of tapping the button to open the door, I had to hold it for half a second. Easily doable with our relay setup. On my 3 button remote, I paired the third, largest button to my opener, but you could probably use any of the three.
Pins for Relay and Reed Switch (Contact)
picture of wiring
Adding Tasmota to SmartThings
This howto uses the Matter protocol to link the ESP32 to SmartThings. Start by logging into the Tasmota interface on the ESP32 and navigating to Configure -> Configure Matter. Check the …
Now we need to ensure the sensors are added to Matter for sharing.
More information surrounding Tasmota’s Matter support can be found here
Linking Tasmota to SmartThings via Matter is fairly straightforward. Start by adding a new device to SmartThings. Select Partner Device -> Matter. The phone will request a QR code - point this to the QR code displayed on the Tasmota device. Once scanned the SmartThings app will confirm that you wish to add a unknown manufacturer. This is acceptable, as the Tasmota/Matter stack is an open source project and not technically a vendor.
The app should now display the Garage Door Relay and Garage Door Sensor (our Reed switch). The first will show the door status, the second will allow you to trigger the garage door. Normal SmartThings functionality will apply in the form of creating Routines and sending alerts.
References
Many thanks to the below
Espressif - their ESP32 devices provide a great platform for my projects
Tasmota - Provides a consistent interface to the ESP32, allowing one to focus on implementation instead of chasing documentation
Digiblur - the idea of leveraging an existing remote came from here; adapted to my model of remote
If I missed any references or any of the above is in some way incomplete, reach out and I’ll attempt to remedy.
This is a work in progress
]]>Radio Controlled Lawn Mower Build (updated after 5 years)2022-10-23T08:00:00-04:002022-10-23T08:00:00-04:00http://www.joshlebo.com/rcmowerProceed with caution.
I am not responsible for the destruction of property or wildlife. Use sound judgement.
This journey will require problem solving as well as trial and error. The below pictures of various builds during my own journey.
Parts List:
Spektrum AR610 RC receiver - $29
Spektrum DXe Transmitter - $60 ( I way overbought on this )
Dimension Engineering 2x60A Motor Controller - $180 (first controller)
Cytron SmartDriveDuo-60 (MDDS60) - $150 (much better second controller)
Cheap Used Lawn Mower - $55
Pride Jet 3 Ultra Wheelchair motors - $100
Pride Jet 3 Ultra Wheelchair tires - $40 (buy these with the above to save time and headaches) Update - used the rims with better tires
Large front caster wheels - $20
Tons of Electronics. 12V to cigarette adapter, switches, wire, etc - $50
Orange strobe light - $20
Arduino Nano (actually a clone) - 5 for $20, so I guess $4 (update: not used)
Sainsmart Dual Relay Board - $7 (update: not used)
Pololu RC Switch and Relay - $10
Steel stock for the frame - $100
Poulan Pro all steel deck lawn mower - $150
Always looking for a project, I decided to build an RC lawn mower. This project seemed to combine mechanical, electrical, and drone experience into one. The idea of mowing the grass from my porch while wearing a beer dispensing helmet always appealed to me.
Making it go:
The very first thing that I purchased from eBay was the wheelchair Motors. I made the mistake of not purchasing matching wheels at the same time. This led to a few false starts attempting to match wheel hubs to the motors. In the end I ended up going back to eBay and buying the correct wheels from the same manufacturer for $40. The only modification I had to do to the wheelchair Motors was to remove the top covers, remove the brakes and cut the electric brake wires. This may sound scary, but while the device is in gear it doesn’t move unless powered.
To convert RC signals into motion, I used a Dimension Engineering 2x60 motor controller. This interfaces nicely with a standard RC controller (from Spektrum in this case). I had to mess with the dip switch settings to get the controls correct. Essentially it’s in RC mode, linear rate, and in mixed mode, not dual-stick tank steering. No additional programming was needed for the RC controller. Testing via a multimeter was helpful. While mapping from the RC transmitter to the Dimension motor driver.
Power is supplied by two RV/Deep Cycle batteries in a series. This puts out 24-25 volts of power. This thing is wicked fast and somewhat twitchy.
Safety Concerns
I wanted the gasoline lawn mower engine to shut off if A) I toggled a switch on the controller B) the transmitter was out of range or C) the transmitter batteries died. I wanted a setup that ‘failed close’ so that the default resting state of the system was to ground the mower’s magneto. This would short-circuit around the spark plug, and the mower engine would shutdown. For the engine to run, the controller had to be in-range, and the relays powered on.
Fortunately, I bought a RC transmitter with way too many toggle switches. After doing some testing with a multimeter, I found that the Gear toggle had a large delta between on and off, and could be read easily with the Arduino. I started by creating a basic program on the arduino, and playing with the input pins on the relay. These devices have a default closed or default open setting, I can’t remember if I had to reverse that while building this project. If the relay board is receiving a HIGH value, the relays are open.
The gasoline engine magneto had a spade connector which was originally used to ground the ignition system when the safety handle was released. All I had to do was run one wire from the magneto to one relay contact, and run the other relay contact to a bolt on the frame. To tie it all together, I used the Arduino program to monitor the value of the Gear signal, then send a HIGH value if we want to engine to run. If that signal goes away for any reason, the circuit collapses and grounds out the engine.
All of the above are sensitive electronics. I went through two iterations of project boxes to protect them. Arduino code found here. HOWEVER, IT DOES NOT WORK.
Everything worked on the bench perfectly, but when I attached it to the actual mower I had quite a bit of feedback and bouncing on the RC circuit. The readings would spike and dip, and the relays would chatter on and off. I tried various circuitry tricks like sinking to grounds and spent hours designing and redesigning electrical circuits and modifying Arduino sketch codes, with no luck. In the end I found a relay that interfaced with RC controllers. The Pololu RC Swich with Relay was worth every penny of $10, and I should have bought that FIRST. Works every time, and lets me shut down the gasoline engine remotely. When the relay contacts close, the ignition coil is grounded to the frame, bypassing the spark plug. So for the engine to fire up, the manual safety must be removed, AND the transmitter must be transmitting a good signal. Any form of failure with the power or RC signal causes the engine to shut off. My original solution was over-engineered. Example video below.
Wiring Diagram
I’ve recieved many requests to share wiring info, so I threw together a crude diagram to get people started. I leveraged the RC airplane controller to operate the motor controller and kill switch relays.
Creating the Frame
One of my most anticipated tasks needed to complete this project was the creation of the frame. I noticed that several RC mowers online made reference to outsourcing the welding - I was interested in doing this myself. My reasoning was that having someone else do the welding the first time around, I may save some money for the first incarnation, but if I needed to re-do any of the design, I’d quickly burn cash. Purchasing a welder and all needed accessories was about $250, and frankly, I REALLY wanted to add this kill to my toolkit. Also, as a side note - if you need a quick cheap and simple surface to do basic welding on, a $10 piece of concrete board works GREAT.
Purchasing steel stock at Home Depot at retail prices was surprisingly expensive. I know that other stores such as Tractor Supply sell steel stock, but I didn’t check their prices as a comparison.
I used angle iron for the main frame, and used smaller box frame for the cross braces and battery compartment. One of the elements that I was most proud of was the creation of the rear axle in the brackets that hold the wheelchair motors. Essentially cut and drilled a piece of angle iron to create the motor mounts. These were then welded to the rest of the frame.
To lower the center of gravity, I recessed the battery boxes INTO the frame. This over complicated the build, and simply wasn’t necessary. Even with the batteries ‘on top’ of the frame, there’s no way this thing is tipping over. Having the recessed sub-frame lengthened the overall designed and hindered the mower deck placement. Update: move the batteries BEHIND the axles, better handling.
Motor brackets leveraged the existing screws on the motor, then welded to the frame.
Once I had it all together, a quick coat of primer and ‘Toro Red’ spray paint from Tractor Supply. Makes it look less scary and more legit.
Mower Deck
For this, I looked for the most basic mower I could find. I figured this would make the conversion easier. I ended up with a 21 inch basic mulching mower. The original goal was to leverage the height adjustment levers and original axles. However, the mower had a lot of plastic junk on both the front and back. I removed the front, and found two metal tabs that were perfect to hang from. The rear of the mower deck was not so easy. I ended up cutting, glueing, and generally hacking the rear plastic section for hours. The resulting rear was screwed closed, filled with expanding foam, and painted with undercoating. Yeah, it was a mess. Next time, I’ll find an all-metal mulching only deck. The mower deck is suspended with adjustable turnbuckles. They seem to work well.
Actual Mowing
It works pretty well, I was surprised. After playing with some of the control settings on the motor controller, I was able to pretty consistently pilot the mower. I opted for a mulching-only mower, as I had no room for a bagging mechanism. Overall, I think I’ll enjoy mowing with this contraption.
Example videos below:
Lessons Learned:
It could be smaller.
It could be a good bit lighter.
Using an all-metal mower deck would have saved time.
I would redesign the rear of the frame with fewer parts.
The battery boxes do not need to be recessed INTO the frame.
Chains for traction may help on hills, I have some wheelspin.
Remote electric start? Might be fun.</li>
Update 5/1/2017 - Tire Upgrade
The original ‘run flat’ wheelchair tires perform well on sidewalks and roads, but prove problematic on wet grass. They were standard rubber tires on the outside, with a foam core. These tires were rock hard, completely round, and would never go flat. I decided that knobby tires with tubes would be better, as I’d get more traction AND be able to lower the pressure within the tires, a good trick for driving a car in the snow. The Jet 3 Ultra scooter that provided the electric motors and axels did come with a pneumatic tire option, but wow, those rims were expensive, even second hand. I eventually determined that I could drill through one of the split-rims and provide access for a tire inflation stalk. The rim modification took all of 20 minutes and isn’t pretty but works. The tires and tubes were purchased from Harbor Freight for $10 each on sale, and were leftover from one of my first attempts to match hubs to the motors. With this setup, I can try many different tire options in the future. Update again: Kenda makes knobby tires in the right size that work great.
After a summer of mowing, I came to a few conclusions. The mower could have benefitted from being shorter and lighter. Having the wheels all the way in the back meant that more torque was needed to swing the frame around. Shifting all weight closer to the wheels helped quite a bit. I suppose moving some of the weight behind the wheels would help even more, but this new design is a good balance of weight distribution and compactness. Also, eliminating the recessed battery box shorted the frame quite a bit. Streamlining the electronics, putting them in a PVC enclosure and nestling them between the motors was a win on all fronts.
Update 7/1/2018 - Motor Controller Fire
While mowing grass, I noticed the controller seemed to be cutting out on a particularly hot July day. I powered down the mower, let it cool down, then tried to power it back on. When it didn’t respond, I began fiddling with wires, checking things with a multimeter, etc. It appeared that a lead on the motor controller itself was coming OFF of the printed circuit board. I’m not sure if it vibrated loose or was melting off of the board. I tried to reseat it, powered the unit back on for testing and poked at it. poof I had a few sparks then an electrical fire. The fire extinguisher stored in the shed was finally called into action.
The next iteration, we’ll call it version 2.1, uses a Cytron SmartDriveDuo-60 (MDDS60). This unit seemed to have a few additional safety features, a design that fosters better airflow, and seem to be a a generation newer than the previous controller. Between ordering the controller and re-wiring everything I was back up and running in 12 days.
Much lighter frame, rear wheels brought in to match the deck width, and batteries behind the rear axles. The mower now handles WAY better. This will be the last build for a while.
On second thought, don’t build one of these.
If you have questions or comments, send them to ‘sclebo05’ -at- gmail
]]>Live Trap SMS Alerting Design2022-10-20T08:00:00-04:002022-10-20T08:00:00-04:00http://www.joshlebo.com/making/2022/10/20/trapalertProceed with caution.
I am not responsible for the destruction of property or wildlife. Know your local ordinances when it comes to the capture and release of animals. Use sound judgement.
The goal was to recieve an SMS notification the moment a live trap has success. This allowed immediate relocation of the animal without visually checking the trap at regular intervals. Picture of the final product below:
Parts List:
ESP32 microcontroller with wifi, I used a NodeMCU - $6 - $10
Reed switch OR contact switch - $4
USB Battery and cable to power the above
PCB and wires to connect the above
Some form of project box, I 3d printed one - $???
Twilio Account for sending/recieving SMS messages - This costs pennies a month
Standard live trap. Can be scaled up or down based on needs - $35
Roasted peanuts, salt free - $3 a bag
Always looking for a project, decided to build a simple notification system that can be used for many purposes. This particular build requires some electrical know-how, soldering, programming, and in my case, 3D printing.
Wiring
It doesn’t get any simpler than this. In essence, an ESP32 microcontroller watches for a reed switch to close via GPIO pins, and sends the text message alert via Twilio. I opted to 3D print an enclosure for the electronics.
The magic comes from the reed switch. This is a simple device commonly used in home security systems. One component has two small metal contacts that are naturally air-gapped. The second has a simple magnet inside. When the magnet approaches the contacts, they bend and touch, completing a circuit. The reed switch was located on the door of the trap with double sided tape, creating a contact upon success.
For the enclosure I 3D printed a project box. Using a utility knife I scored and snapped a printed circuit board to fit inside. With a few soldered joints the ESP32 and jumper wires were securely in place.
Programming
The ESP32 supports CircuitPython as well as the Arduino IDE. I chose the latter to quickly cobble together a few existing libraries and get the device deployed. The device connects to my home wifi and then calls Twilio for the alerting. Twilio is a service with callable programming interfaces that function as a cloud based texting service. Call the APIs with the message and destination phone number, and they send the actual text. The main loop of my code watches for the reed switch to close, and then calls the Twilio library to send the text message. The wifi and library setup comprises the bulk of the code. The code is written in a manner that only sends the alert ONCE.
Place peanuts at the BACK of the trap, with a trail running out the front. The squirrels will run off and bury the peanuts outside the trap, and become braver with subsequent trips.
Open the trap door and set the trap as normal. Plug the ESP32 into a standard USB power brick, and you’re set. The power draw is minimal, and even a cheap power brick lasts all day.
Configuration of the Twilio account is beyond the scope of this article. The library within the Arduino IDE handles all of the heavy lifting, the user simply needs to register a Twilio account, select a source phone number and copy the account IDs to the code. Each text message costs something like $0.00001, making this service very affordable. Sample SMS message below:
Lessons Learned:
The ESP32 is a nice balance between cost and power, occupying the space between an Arduino and Raspberry Pi
Reed switches have countless uses for home security
No creatures were harmed during the completion of this project.
If you have questions or comments, send them to ‘sclebo05’ -at- gmail
]]>Recover A Thecus N2100 from OpenBSD2019-02-17T07:00:00-05:002019-02-17T07:00:00-05:00http://www.joshlebo.com/making/2019/02/17/thecusn2100debianTable of Contents:
I purchased a used Thecus N2100 on ebay, that had been altered to run OpenBSD. I BELIEVE the previous owner used this guide to perform the installation. My intent was to install Debian linux to replace OpenBSD. Unfortunately, installing the OpenBSD bootloader required the deletion of userland tools from flash due to space constraints. This removes the ability to re-install the original factory firmware, and in turn, prevents the installation of Debian. Using these steps, I was able to restore the unit to original factory condition. After this, installing Debian worked as expected.
Still reading? Anyway, I really didn’t use any tools for this project. The only required object is the Thecus N2100, and a second PC of some sort. If you wish to open up the chassis to swap hard drives, etc, a #2 Philips screwdriver will work fine. To perform this recovery, I actually had a second working Thecus available, and was able to use its flash to recover the broken unit. I can provide memory dumps if this data if needed.
The box booted just fine into OpenBSD, but I can see how the following would help a box that can’t even do that. Most of the Thecus boxes that have been updated to a fairly recent flash will have Redboot, a bootloader/utility that provides basic functionality to booting and recovering the box. See this guide for more details about accessing Redboot.
To access Redboot requires telnetting to port 9000 during the device’s boot process. The easiest way to do this is with the following:
arping -f 192.168.1.100 && telnet 192.168.1.100 9000
WARNING: interface is ignored: Operation not permitted
ARPING 192.168.1.100 from 192.168.1.104 eth0
Unicast reply from 192.168.1.100 [00:14:FD:10:33:8E] 6.473ms
Sent 9 probes (9 broadcast(s))
Received 1 response(s)
Trying 192.168.1.100...
Connected to 192.168.1.100.
Escape character is '^]'.
== Executing boot script in 2.650 seconds - enter ^C to abort
^C
RedBoot>
RedBoot>
On my working Thecus, the following command showed the contents of the flash disk:
RedBoot> fis list
Name FLASH addr Mem addr Length Entry point
RedBoot 0xF0000000 0xF0000000 0x00040000 0x00000000
RedBoot config 0xF0FC0000 0xF0FC0000 0x00001000 0x00000000
FIS directory 0xF0FE0000 0xF0FE0000 0x00020000 0x00000000
ramdisk 0xF0040000 0x00800000 0x00D00000 0x00800000
kernel 0xF0D40000 0x00200000 0x00160000 0x00200000
user 0xF0EA0000 0x00120000 0x00120000 0x00800000
Notice the ‘user’ directory. This is where the userland Linux tools are stored for the default Thecus firmware.
The ‘user’ directory had been replaced by a ‘boot’ image of a different length. When I tried to manually load and boot the kernel and ramdisk, they appeared to get started, but once the kernel booted, the lack of userland tools meant no web interface, no network settings, basically a dead system. How do we get this back?
The working Thecus already had Debian installed on it, and provided all of the tools needed to extract the original Thecus firmware for the transplant. Looking at the forums, I determined that the flash was accessable under /dev/mtd*. To view which partitions housed the various flash images, simply view /proc/mtd. Observe:
This looked familiar. I was able to mount these with mount -t jffs /dev/mtd3 /mnt/temp or something similar, but I wanted to extract the filesystem in its entirety. After playing with dd, cat, and /dev/mtd3 and /dev/mtdblock3, I found that a simple
cat /dev/mtdblock3 > user
appeared to do the trick. I now had a file called ‘user’ which had the contents of mtd3.
Importing the user image to flash proved to involve a bit of trial and error, and having made a few typos while I figured out which flags on the fis command did what, I was lucky to not blow away any other images ;)
From Redboot, I ran the following to erase the ‘boot’ image:
fis erase -f 0xF0EA0000 -l 0x00020000
Now load the ‘user’ image via tftp from the server 192.168.1.5 to the correct memory location:
ip -h 192.168.1.5
load -r user -b 0x00120000
Now the moment of truth, flashing the image from RAM to the onboard flash chip. No mistakes!
RedBoot actually boots the system, so we have to set it to load the kernel and initrd into RAM, then run the userland tools that set the device IP and console access. Recreate the original boot script using fconfig in RedBoot:
RedBoot> fconfig
...contents of the script below...
thecus_setip
fis load ramdisk
fis load kernel
exec -c "console=ttyS0,115200 root=/dev/ram0 initrd=0xa0800000,42M mem=128M@0xa0000000"
Set any IP or other settings that you like. Reset with ‘reset’.
At this point, the unit booted into the original Thecus firmware! I upgraded to the Thecus firmware to 2.10, the latest version, then followed the Debian installation guide. The unit installed with no issues, and OpenBSD was gone forever. Eureka!
Below is a list of most of the articles I used to piece together this procedure. Thanks to the original authors, as without the background information, I would have never recovered this piece of hardware.
That about wraps it up. This is a fairly straightforward hack that will allow you to run Debian in all of its glory on hardware that has a limited distro on it. If you have any thoughts/additions, email them to sclebo05 AAATTT gmail.com. Thanks for stopping by!
]]>Washing Machine Text Alerting2018-04-17T08:00:00-04:002018-04-17T08:00:00-04:00http://www.joshlebo.com/making/2018/04/17/washeralertingArticle originally created 4/17/2018
From time to time, when I’m out in the garage or off somewhere in the house, I forget about my laundry. Or worse, I check on my laundry and find that it’s not done. While not the end of the world, it is inconvenient. I saw that some modern washers have notification apps to solve this problem. Since the washing machine that came with our house still functions, I decided to retrofit a notification system to it.
Items Used and Cost:
Raspberry Pi Zero W - $15
A 3.3v or 5v Vibration sensor, for Raspberry Pi or Arduino - $4
A piece of breadboard, a moment switch, a resistor, some wire, and solder - $5
An old cell phone charger that I had a box of junk - FREE
An old Roku 2 Case, or any enclosure - FREE
Python Script to monitor the sensor and send text alerts - $$$ (Whatever you value your time at)
Twilio.com Account - $0.0017 per text
I really thought about using a Sardine can for this one.
The wiring schematic found on the site referenced below allowed me to put together a few circuits on breadboards for testing. The Roku 2 streaming device case had a perfect location for an LED indicator, which I incorporated into my programming as a status light. I then soldered everything together and superglued standoffs to the case to best position everything. Of note, nylon standoffs are my favorite thing ever.
I spent most of my time merging together a few Python scripts into something I liked. Using callbacks as opposed to putting a button event in the center of the main loop seemed to make the most sense to me. When the sensor is motionless for 5 minutes, a text alert is sent. A link to the actual python app is also linked below.
The alerting was the fun part. I found that Twilio.com had a ready to go Python library, and rediculously inexpensive text plans for the hobbyist. The script logs to a file and outputs to standard out if debugging is needed.
Currently I have the device perched on the washer (or dryer). Seems to work pretty well so far. Sample code is: here
If you have questions about any specifics, email me at sclebo05 —AT— gmail
]]>Installing Debian on a Thecus N52002017-05-05T08:00:00-04:002017-05-05T08:00:00-04:00http://www.joshlebo.com/making/2017/05/05/thecusdebianHow to install Debian Lenny on a Thecus N5200, using an external USB CDROM
Still reading? Anyway, not many tools are needed for this project. We use a Thecus N5200 (obviously),
screwdrivers, pliers, Debian Lenny install disc, systemrescuecd.org disc,
External USB CDrom drive, an old VGA cable, and a USB keyboard.
First, remove the rear panel of the case, being careful to unplug the fan as it is removed.
Remove the main housing of the Thecus. Remove the two screws from the second gigabit network interface
riser card, and set it aside. Remove all SATA drives of course.
Beneath the gigabit riser card, you will find an array of leads at the edge of the board.
These leads would be where the VGA plug would be soldered into the board. Using pliers and little bit
of patience, we were able to create a monitor cable with bare pins, that fit perfectly into the board,
giving us a VGA signal. See the pictures below. NOTE: We noticed that the monitor cable was getting
close to touching various components on the board, so we created a little cardboard separator to place
between the cable and the board.
At this point, we were able to boot the Thecus, press the Del key, and enter the bios. Its a pretty standard bios.
We did adjust the boot devices order under the Advanced settings, adding our USB CDROM and USB Harddrive (for later).
We left the internal IDE as a third option. Save and exit.
To prevent confusion, and to protect the original OS on the IDE flash memory, we removed it. We found that wiggling it
up and down allowed it to be removed easily. We were able to find a very small 8GB flash drive for very little cost,
and used that to serve as our hard disk. Understanding the risk of failures, we will have images of the OS
drive and incremental config backups to help protect us. Dumping images to pen drives is pretty easy ;)
We also cabled up an external USB CDROM drive at this point. The adapter we found supports IDE, SATA, and laptop drives.
Very inexpensive also.
We chose Debian Lenny as the OS, as we were familiar with it, and it is easy to maintain. We won’t go into the
details of the install, but there are a few points to be aware of:
You may have any partition scheme you want on the flash drive, but it is recommended that you do NOT use
a journaled filesystem, due to speed/repetitive journal issues with flash storage. We chose a single root partition formatted with ext2
create a label on the partitions. This became VERY IMPORTANT, as we found out later that the flash drive appears
as an sda device. Things really got interesting once we started installing SATA drives and drive enumeration would jump around based on the number of drives.
When the install finishes, you should be able to boot to Lenny. Everything seemed to work for us with no tweaks.
At that point, we immediately edited our /boot/grub/menu.lst and removed references to /dev/sda1 and replaced them with
root=LABEL=*labelname* . Also, in our /etc/fstab we replaced any references to sda* partitions with LABEL=*labelname*.
Reboot, and ensure everything works. If not, use your systemrescuecd to recover the box.
If you forget to create labels during install, its easy to do e2label *device* *labelname* on your partitions
The first tweak to perform is to add ‘noatime’ to the /etc/fstab line pertaining to the partitions on the flash drive.
This prevents the Thecus from updating the access time on files that it touches on the flash drive. There are similar options
like relatime that help with apps like mutt that rely on atime. See man mount for more info.
We plan to add other functionality, such as LCD control, apply the kernel patches we have found on the net, etc.
Check back to see our progress.
Oh, at this point you can re-add your SATA drives and build new partitions if you like.
We were able to reassemble the ‘old’ Thecus drives/partitions with
That about wraps it up. This is a fairly straightforward hack that will allow you to run Debian in all of its glory on hardware that has a limited distro on it.
If you have any thoughts/additions, email them to sclebo05 AAATTT gmail.com. Thanks for stopping by!
]]>Graphing Avaya IP500 PRI Usage2016-01-20T07:00:00-05:002016-01-20T07:00:00-05:00http://www.joshlebo.com/making/2016/01/20/avayasnmpThe Avaya IP Office 500 PBX does not appear to have an easy way to graph PRI usage.
We discovered a status packet sent by the phone system to Xima that contains the number of current calls on the PRI trunks. We need to convert a packet on the wire into a WhatsUp Gold Graph.
I have created a crude proof of concept using a physical server, tcpdump, perl, snmpd extensions, and WhatsUp Actionscript. Any or all of these pieces could be replaced/refined if need be (for example, we could use a VM or sed instead).
I created a Cisco span port that replayed the traffic between the PBX and Xima, and attached a physical server to it.
Start with capturing the packet on the wire:
/usr/sbin/tcpdump -nn -v -i eth1 -s0 -A host and host and udp
In the below mess of a packet, you can see CALLS=2
What a mess. Regex time! So I put together the following Perl script, could be replaced with bash or another language
#!/usr/bin/perl -w
# by jlebo to capture trunk calls on PRIs from Avaya phone system
use strict;
my $callcount = '0';
my $outputfile = '/tmp/trunkcalls';
open(STDIN,"/usr/sbin/tcpdump -nn -v -i eth1 -s0 -A host 172.27.105.5 and host 172.27.105.6 and udp | " );
while ( <> ) {
if ( $_ =~ /C.A.L.L./ ) {
#print $_;
$_ =~ s/\.//g; #remove periods
$_ =~ /CALLS=(\d+)/ ;
$callcount = $1;
#print "So calls is $callcount\n";
open(OUTFILE, ">$outputfile") or die "Cant open file\n";
print OUTFILE $callcount . "\n";
close OUTFILE;
}
}
exit 0;
The PBX sends these packets every minute. The above outputs the number of trunk calls to /tmp/trunkcalls as soon as they are recieved.
Now to configure the Linux SNMPD to display the contents of the above file. Created the below snmpd.conf file, which creates the custom OIDS
Entered the info into an SNMP monitor and … FAIL. WhatsUp complains that “The polled value was not numeric”.
Here’s where it gets fun. Extending Linux SNMP OIDs in this manner ALWAYS returns a string. Most monitoring systems are smart enough to convert a
string of numbers to an integer number - WhatsUp Gold does not do this. Instead of a simple SNMP Performance Monitor, we have to create a Custom ActionScript Performance Monitor.
In the Performance Monitor we first create a Reference Variable from the above 2 part OID while the below code converts the string to an integer.
TrunkCalls = Context.GetReferenceVariable("TrunkCalls") 'import variable
TrunkCalls = cInt(TrunkCalls) ' does the conversion
Context.SetValue TrunkCalls 'write it back
Now we simply add the Performance Monitor to the device in question. Changing the frequency on the performance monitor to 1 minute gives good granularity.
