Halmidor: Internet-Connected Humidor

Halmidor: Internet-Connected Humidor

The Background

“Why don’t we make an internet-connected humidor?” 

In the summer of 2016, I was in Seoul, Korea, representing myself as a guy who was looking to connect devices to the internet.  Coming from the Arduino side of things, I was more of a ‘hardware’ guy.  I was introduced to a python programmer, someone on the ‘software’ side, who was interested in similar work.  We met at our mutual friend’s cigar bar, Burn in Hal, in Kyungridan, Itaewon.  After some smoke and drink, my new friend asked, “why don’t we make an internet-connected humidor?” 

It was kind of a joke.  But in the end, it wasn’t.  It would eventually become the home of my first internet-connected device, the Halmidor.  And the technology behind this connected humidor would eventually become the basis for what today is the OhioIoT platform.

The python programmer got into a blockchain project, and went radio silent.  But I was already on a path to learn Javascript, so I took the web programming side for myself. 

But, some other new skills needed to be developed as well:

  • circuit design
  • 3D printing
  • XBee radios
  • Raspberry Pi and linux
  • JavaScript (React/Redux) to make the web app 
  • lastly (enter the real world), getting my end device to talk to the humidifiers inside the humidor

It became a monster.

It shouldn’t be complicated, right?  Don’t add too many features!  Just get a basic system working.  We did that…  And then found out quickly all the reasons why a basic system would not cut it.  You could graph your data in the app, so long as you didn’t have to restart your app.  You could save your settings in variables, once again, so long as you didn’t restart the app.  And so, it was time to write a database…  By the way, what if the box lost radio communication?  It did.  Often.  Any changes to the settings needed to be saved to EEPROM, so the setting would restore on boot up.  Then we needed to code so that the database, the Halmidor, and app, would always be looking at the same information, no matter where the change was made.

It got worse.

What if an alert was fired, but the app wasn’t open?  More databasing was needed to catch the alerts.  Well, Was this mission creep?  It was supposed to just be proof of concept.  But if the user acknowledged getting the alert flag, and cleared it, another alert would fire if the box was still out of spec. 

We needed a second flag, and screen functionality, to say whether or not we wanted to resume regular operation.  On and on.  The point is, it wasn’t really possible to just make an app that could turn something on or off through the internet.  In practical reality, this was an operating business that cared about the humidity of its cigars.  And the initial joke was demanding serious effort.

What I didn’t know was that in that process, what was forming was the groundwork for what would be the actual OhioIoT system for doing IoT.  The problems that I was solving at that time actually apply to almost any other situation where people want to connect hardware to the internet.  And so, a platform was being born.

Timeline To Today

August 2016 – The meeting at Burn in Hal where we decided to make a internet-connected humidor.


September 2016 – It was an Arduino AND an Arduino Mega (yes, two computers to do one job), driving two LCD screens.  It measured the humidity and reported it, but we couldn’t get it to talk to the humidifiers.  So, I left Korea empty-handed.

Early Fritzing documentation

Fortunately, Fritzing exists, and I was able to document the wiring

October 2016

The python programmer disappeared to chase his cryptocurrency dreams, but fortunately I was already in the process of learning JavaScript.  I started developing the web app on my own.

March 2017

Back to hardware development.  This included 3D-printing a box.  By the way, there is a learning curve in making boxes for your devices.

3D Printing basic outline

redesigning the box on AutoCad

Solid rendering of the box

preparing for 3D print

Roughly assembled prototype

Arduino and Pi stuffed in a box…  hey, it was my first project.

Snapping it all together

little red monster


April 2017 – This time, we got the box to talk to the humidifiers.  But, we needed to work on the timing of pulses to the switch, to make the humidifier think that it should be on or off.

With a box that was talking to a humidifier, we finally had a internet-connected humidor.  I went full-time on creating the web app.

Wiring up to control the humidifier

Two wires to fire the switch, and two more for the photoresistor, which senses if the box is on.

With a box that was talking to a humidifier, I finally went full-time on creating the web app. 

Screen shot of the Halmidor.com app

Spent weeks developing this

The Rasbperry Pi wouldn’t connect to the wifi.  We never came to understand why.  Instead, we started over on a breadboard, and made the Arduino talk to the Raspberry Pi through XBee radios.   This allowed us to plug the Raspberry Pi directly into the ethernet upstairs.  And, this would become my default starting point for IoT, as it eliminates the hassle of trouble-shooting wifi.

An attempt to connect by XBee

The version we eventually went with.  XBee in the back corner, to talk to the Pi upstairs.

What a memorable night – sitting at dinner with my girlfriend and turning the connected humidor on and off – from our dinner table a mile away!  

Anyway, more reliability issues surfaced.  The box stopped working soon after I left for the U.S.


May 2017 – Back to work in the U.S.

I needed something more rugged than wires plugged into an Arduino.  This time I learned about proto boards.  And by the way, I recommend you don’t ever go this route.  It’s awful.  Go straight to PCB CAD design.

New pieces, ready for test
Very hard to pull this off, but at least the wires don’t fall out anymore, because they’re soldered.
Piecing together the next-gen Halmidor
Leaving room for the LCD
Fit check:  looks like everything will get inside the box

Fit check ? .. pass.

Powering up the new guy

let’s fire this bad boy up

Assembled next-gen Halmidor

More 3D-printing hell.. Make sure you outsource this part for your project.


June 2017 – back in Korea

Coffee and firmware uploads

Some on-site tweaking of the code

Getting some good data

It’s alive!

Taking several data points for thoroughness

..and working.

The humidor is under control

In a little less than a year, and after three visits to Korea, the connected humidor was in operation.


September 2017 – Back to work in the U.S. again

Learning to use the PCB CAD

I discovered the CAD aspect of Fritzing.  Well, Fritzing is probably not the last CAD software you want to use, but it might be the first.

What the PCB will look like

No more soldering up the proto boards.  Now the wiring could come in the mail, already connected.

Getting better at making boxes

And, my 3D-printing skills were improving.

Each revision brings a smaller form factor

new model on the right – no wires!


June 2018 – Back in Seoul, delivering a younger, more powerful model

Old and New Halmidors

The little brother arrived.

Want to Talk to a Box in Korea?  Who Doesn’t ?!


If you go to Halmidor.com, you can see the live data streaming from the device inside the bar in Korea.  When the humidity is below the defined limits, you know that Hal’s staff has not replenished the water washers.  But if it’s running high, you know that the air conditioners, which are sometimes required to dehumidify the air, are not on.  Should you see the humidity spike down several times within an hour, you know that they are selling cigars, because someone keeps opening the door and letting in dry air. 

I JUST took this screen grab.  It’s Thursday night in Seoul (~10:45pm):   [[[[ internet-connected humidor ]]]]]

The app says he's selling cigars

You can see that in the last hour, they got two sales (red arrows).  Also, you notice

that the status is “Off”, and the humidity is currently declining (yellow arrows).

You can even talk to the Halmidor without a login.  If you click the SpeedTest button, a command will travel from your phone or computer, to a server in New Jersey, to a Raspberry Pi on the 2nd floor of the bar, in Seoul.  That RPi will send a radio packet down to the end device inside the humidor (the “Halmidor”) on the first floor.  The Arduino inside the Halmidor will acknowledge receiving the packet, which will then make it all the way back and round-trip time will report on your phone or computer.  This is typically less than 1/3 of a second.  Not bad, eh?




A conversation in a bar, turned into a connected humidor project, which got overly involved, and then resulted in the creation of the system that could eventually be sold to customers.  What is selling as OhioIoT today is about 20 times as much code as the Halmidor, but the genetic make up is about 80% shared.  

And, although I’m not a big cigar smoker, I certainly like to go back to Burn in Hal and hang out, reminiscing about the battles we went through to create OhioIoT’s first project.


What We Learned at CES / Eureka Park

What We Learned at CES / Eureka Park

Welcome to Eureka Park

In January 2019, OhioIoT attended the Consumer Electronics Show in Las Vegas.  We exhibited in Eureka Park, the designated area for startups.  It was a great and intense week.  We spent a lot of money, learned a lot, and had fun.

Here’s a rundown on what we took away:

Signing Up

Guess what – most of the companies that are attending in 2020… have already signed up.  If you are thinking about getting to Eureka Park next year, now is the time to get on the internet and figure it out.  If you are signing up now, don’t despair.  We signed up in August, and were very worried about our original placement – all the way in the back of the room.  But there are two things to note:

  • First of all, the entire floor was packed with people.  We thought you needed to be near the front to get enough exposure.  But this was not really the case
  • It’s a fluid situation.  We politely called in to inquire about our location.  With a little nudging, we ended up getting moved twice, and by the second time, we were all the way to the front of the room.  I’m not saying this will work for everyone, but it is apparently a possibility if you get on the phone

Lock up your hotels as soon as you get accepted.  Attendees get a very good rate at some of the downtown hotels.  You can cancel your rooms before the event, but you cannot add a room if they are booked, so start big.


Ready for action at the booth

Fired up, and ready to sell

Contact Information

I originally put down my mobile number and email as the primary contact for the company.  This was a mistake.  After the spam calls started coming in, I created a Google Voice number to serve as the new company number.  The spam calls to this number eventually died down.  But, to this day I am still getting unsolicited email advertisements with no unsubscribe button.

For your CES directory listings, I strongly advise creating alternative contact points that you can turn off after a couple of weeks or months.


Lightening sound effects

Plugging in our internet-connected lightening sound effects, which could not be heard during the show.


Here is a rough breakdown of the expenses that we incurred for the week:

    Booth:               $1,000
    Internet and power:  $1,300
    Backdrop:            $1,200
    Flights:             $1,400
    Hotels:              $1,700
    Meals:               $1,200
    Taxi & Uber:           $400
    Shirts & Bus. Cards    $800
    Printed Materials      $200
    Booth Decoration:      $400

That doesn’t include everything (and no, casino expenditures were not expensed!), so it’s fair to say the week went for $10K.  Does it have to be that much?  No.  But it could also be more.  You can save some money by having a smaller team, stay few nights in the hotels, and also reduce your booth graphics to just a backdrop image.

Attendance costs $1K, but your starting budget should be somewhere near $5K, going up to $10K or $15K depending on your situation, or desire to impress.

Team dinner at the Venetian

Trying to blend in the with the civilian population at dinner.

Preparation Checklist

I was full-time, seven days a week (including Christmas and New Years) from October 17th until the conference in January.  Where did all the time go?

Well, for starters, going to CES was stretch goal for us.  You haven something, you want to get it out there.  You’re ready for the big dance.  But, once you’re officially going, what features would you like to have ready, at a minimum?  Undoubtedly, even if you are feeling ready for CES, you still have a deep pipeline of problems you will want to solve, and features you want to add.  Do you really think you can let yourself relax thinking, “we’re blowing $10K next month, but let’s just leave these features off the table for now”?  No, you run headlong into late nights trying to make sure everything possible is incorporated for the big week.

But, you also need to take part in other non-OC types of activities.  Here are some notes that I had at some point:

The team:
    - who's going?
    - are hotels and flights are booked?
    - what will they wear?  order shirts, if necessary.
    - do they have business cards?
    - do we have a schedule to get on the phone and agree on talking points?
Booth materials:
    - back-drop graphics
    - side-panel graphics
    - any stands to hold equipment?
    - ethernet switch and wifi router - you'll need both
    - when is everyone arriving?
    - where will you meet to deliver the badges
    - who will be in the booth, and who will travel around the exhibition


For booth furniture, we took a risk that paid off.  Instead of taking furniture with us, at both tremendous cost and inconvenience, we just went to Home Depot in Las Vegas, bought some planks, nails, glue, and a hammer, had Home Depot cut the wood to length, and built ourselves the required furniture in the booth.

The Wood That Would Become Shelves

those became our shelves.


Go out before the show starts, and stock up on bottled water, snacks, and Red Bulls to put inside your podium.  You’ll often find you don’t have time to go eat.

Descending upon the Rock Club

“it’s night time.  you can take your badge off now.”


The show runs Tuesday until Friday.  Most people set up on Monday.  We arrived Saturday night so we could begin set up on Sunday morning.  That turned out to be needed.  Sure, it can be done in a day.  But if you’re not sure, it’s just another $100 of hotel.  Is it worth missing the opening bell?  Why not take some extra time, and perhaps a breather, after months of preparation.

On Tuesday morning, don’t rely on the buses from downtown to get you there.  There’s queue.  Just plan on waking up early, and paying some Uber surge pricing.  

If you want dinner anywhere in the area, you should probably have that reservation set well in advance.  Everyone else does, too, and a lot of the restaurants are closed to private parties.  Of course, if you get away from the show, things open up a bit.

Looking forward to the casinos?  You’ve got more stamina than we do.  When you wake up at 7am and talk non-stop for nine hours until 6pm, and then have a pint or two at dinner, your desire to hit the casinos fades fast.  And, there’s something else to consider.  You probably collected hundreds of potential contacts, whether it be from your notes, or just business cards.  It’s a struggle to remember all of these conversations, and you will have just as much activity the following day, compounding the problem.  Consider leaving over an hour in the morning to parse through these notes and clean up your contact lists, before more information starts coming in the next day.

Fielding questions at the booth

“Yes, the little cactus is for sale.”


When you get your login as an attendee, you suddenly have access to the directory of everyone who will be attending.  There’s a slight adrenaline rush because you are now in the club of all the other people that are launching businesses.  You instinctively start going through these lists and prioritizing conversations.

But, here’s the thing. ..You are going to have so many offline conversations (probably as many as you can physically handle), you don’t need to buttress that with a list of emails that need to go out.  If there is a company you are really interested in, you will be free to visit their booth.

I got a lot of phone calls and emails requesting meetings.  But these were, in ALL cases, someone who was tasked with cold-calling the Eureka Park database, to sell their services.

There are also lots of formal invitations, and pop-up invitations, to cocktail parties.  You imagine that you will be dancing until 2am, and hanging out with Sean Parker.  In reality, these parties are hosted by people who are promoting something.  Unless you are a potential buyer of their services, you may not need to be there.  And.. the entire team will be exhausted.  We dined and crashed every night, because we knew we would be standing on our feet and talking for another nine hours the next day. 

You don’t want to miss the chance to meet someone.  But the people you want to meet are walking into your booth all day long.  Of course there are some killer connections to be made at night, but just attending any cocktail party puts you in touch with the broader population of attendees, with a lower chance of meeting someone who is specifically interested in what you do.

Downtown Las Vegas

“Am I making sense?”       “well.., sort of.”                      


I estimate that we collectively have about 1000 conversations over the 4-day period.  This converted in two immediate new customers.  But, probably the biggest benefit to being there was that our entire business strategy was turned inside-out by the feedback we got.  We thought we were selling to consumers, but left realizing that the path was much clearer for selling to businesses.  At a cost of $10K total, that’s $10/conversation. 

We had a booth graphic that read, “Make Your Own IoT”.  This is exactly what people would read before they walked into our booth.  So, that’s not just $10 per conversation.  That’s $10 per conversation with a highly qualified lead – someone who is already looking for a way to make their own IoT (or whatever it is you are doing in your case).  That’s a lot less expensive than any focus group you will ever put together.  The feedback for us was invaluable, and that’s why, in the final analysis, we found Eureka Park and CES to be totally worth it.




Sun setting on Vegas

A beautiful week had finally come to an end.  Time to return to Ohio.

Should You Be Using a Gateway For Your IoT?

Should You Be Using a Gateway For Your IoT?

Should you go straight to your wifi router with your IoT devices, or should you have an IoT gateway?  What to consider…

Currently, almost everything we do is designed around using a Rasbperry Pi as an IoT gateway that attaches to the internet through an ethernet cable, and talks to end devices through XBee radios.  We do it this way for range and for reliability.  But with the likes of the ESP8266 and ESP32 out there, XBee radios and the Raspberry Pi gateways look a little expensive.  The decision to use an gateway is not an easy one to justify.  Not only do you add cost, but you add the number of components used (and boxes that need to be assembled, power cords that need to be ordered, etc.).  So, why do it?

With the Pi at ~$40 and XBees now at ~$20 (you need at least two), you will pay about $100 more to get the benefits of a connected gateway.  For us, it’s worth it.  But not for every situation.  Here’s what we have to consider each time:


Wifi is often good.  But ethernet pretty much works all the time.  If you are chasing 100% fidelity (whether you actuall get it or not), then go with the ethernet-connected gateway.  IoT Gateway

The first OhioIoT project (the Halmidor) was saved when we realized we could fix our wifi issues by simply plugging our Pi gateway into the router.  In a cigar bar in Seoul, South Korea, an Arduino was monitoring the inside of a humidor, and talking through wired serial communication to a Raspberry Pi, which was in charge of maintaining a wifi connection to our server.  Despite a successful mock-up at our apartment, the box just wouldn’t connect to the wifi at the bar.  We never found out why.  But with two XBee radios in the tackle box, we plugged the Pi into the router upstairs and replaced the wired link with radios.

You can still get live data from this device, operating two years later, at halmidor.com

Local Functionality

A gateway is a place where you can drop some localized code.  I find the new buzz around edge computing to be slightly awkward.  I think of edge computing as computing.  It’s only if you come from a place where everything has to go to the internet that you find it profound to discover that computing can be done not in the cloud.  Nothing wrong with some work that doesn’t include cloud hits.


For some use cases, delays of even a few hundred milliseconds don’t feel right (think, lights turning on in a dark room after you have entered and triggered a motion detector).

Socket connections (socket.io in javascript) are fairly instant.  But MQTT and standard REST requests are a different story.  And, remember that an ESP needs to successfully confirm its wifi connection before it can send.  Going to the internet for everything can slow things down.

XBee to edge device round trips are about 20ms, so if your logic is on the gateway, the system’s reaction times are imperceptible.  If speed is critical, you’ll want to process some decisions at the gateway.


It’s debatable whether or not IoT has a security problem as many people claim. The problem is only when people just actually don’t implement security.  But when proper security measures are taken, IoT doesn’t have any more of a problem than any other vertical.

But regardless, it will always remain true that a cloud hacker cannot access data that is not in the cloud, so… When security is that one step more important, or you don’t have tangible reasons to send everything to the cloud, then why not develop your app on the gateway, and send only relevant bits to the cloud?  As you add the number of end devices, this will have cost implications as well.

Server Cost

When you have a scaled-up implementation, you can have hundreds of data points coming in every minute.  I do at my home.  Those don’t all need to go to the cloud.  You can do some averaging locally, and then send processes packets at one time in a single report to your server.  If every piece you are ever collecting goes up, at some point your server costs will start to drift higher as well.  Some conditions require immediate reactions, so I have edge devices reporting every couple of seconds.  But the reports on any decisions made only need to get to the cloud every 30 seconds.  A gateway helps to smooth this flow.


SSIDs and passwords don’t change all the time.  But they do get changed occasionally for whatever reason.  When they do, you’ll need to reset the SSID and password on each of the devices in your location.  If that is twenty devices, you’re obviously not going to enjoy the transition.

If devices are on a radio connection, they are unaffected by any changes to the internet setup.


If you are building for yourself, you can hardcode the SSID and password, make sure it’s working, and tweak things if they don’t.  If it’s a matter you creating something for yourself, there are very few excuses for why you should start with a gateway and radios.

But what if you are you creating something that might be distributed?  If you are distributing your devices, you are at the mercy of that location’s wifi.  And if the wifi connection doesn’t work, you’ll probably be fielding the phone call.

One last advantage of a Ethernet-connected gateway is that it will work exactly the same, no matter where you put it, whereas the intricacies of different wifi setups may cause problems as you share your technology.



If you are simply attaching a sensor or actuator to the internet, a lot of this talk of IoT gateways and radios probably just feels like more homework for the sake of homework.  And I would avoid that.  But if you are considering a system that is long-term, expected to grow, and focused more on reliability than cost, I would still point you towards the gateway.

Of course, one has to acknowledge the inroads made by the ESP8266, and now the ESP32.  In fact, we are currently converting a lot of our early devices to ESPxx platforms to make them more cost effective from a consumer point of view.  But it’s still new territory.  You’re comments are welcome if you can comment on a history of success with these devices.  Maybe I’ll be espousing the ESPxx’s like every else in a few months, once we establish a good track record.

But until then, our IoT gateway will be enjoying a bit of job security.