Zojirushi: The Perfect Travel Mug

Standard

Ok. Maybe it’s not perfect for everyone but it seems to be a great choice for a technology professional that travels off-and-on. Back in 2017 my reliable Thermos-brand travel mug started to leak around the seals of the lid and rather than simply purchase a direct replacement, I decided to look for something new.

This particular one, a Zojirushi Stainless Steel Mug (16-Ounce, SM-KHE48AG) caught my eye, perhaps because of its simple design, as well as the locking cap. It’s small enough, and with the locking cap, perfect for tossing into a backpack when traveling. Even if you have a laptop and other devices in the same bag. While my previous travel mug did not leak very much, the lid was not secured in such a fashion.

The reviews were very positive, it wasn’t expensive (just under $25) and it looked like a good size.

And it has been. I have indeed taken this to conferences, tossing it into my backpack and carrying it around like that much of the day. It keeps coffee hot for long periods of time. In fact, due to how the lid itself is constructed, I’ve let it open for over an hour and just watched the steam continue to flow out of the top, waiting for it to cool enough to drink.

It’s been perfect, but the first one I ordered had one drawback. It was too tall to fit under a Keurig, even with the removable base of the Keurig pulled away, which meant that I had to brew the coffee into a standard mug and then pour it into the Zojirushi.

I know, I know. That’s not necessarily a deal breaker but when you’re never certain if you’ll find your coffee mug, or at least find it clean, in an office breakroom it can be a bit of an inconvenience.

This year I ordered the 12-ounce version of the Zojirushi Stainless Steel Mug ($22, SM-KHE36AG), which fits perfectly under the Keurig. And, aside from size, it’s no different from the first one that I purchased. It’s even the same color.

If you’re looking for something to keep hot liquids in, or even cool liquids, I highly recommend this.

Using a FITNATE Mist Maker for Small Fog Effects

Standard
Mist Maker in Action

At some point, before Halloween last year, we ended up with a plastic cauldron. I thought it would be fun to have fog bubbling out of it, but rather than deal with dry ice, I decided to look for an alternative.

And sure enough, I found the FITNATE Mist Maker on Amazon for only $16 (the price has since dropped closer to $11). The device is rather simple. It generates a small bit of mist/fog using ultrasound to atomize water into a light vapor. It requires a very small amount of electricity and needs nothing else more than water. The built-in LEDs help to create a more otherworldly effect.

I’ve tested it in a sink, a couple of times and yes, I also used in a cauldron around Halloween. It worked great for our purposes. It’s a great price and worked perfectly. Note that you’ll get a good amount of fog for something like a cauldron but don’t expect to get enough for anything much larger, like a small stage. 

Neat and Orderly: The Benefit of Cable Ties

Standard

Cable ties may not seem like a big deal to many people but any time you’re dealing with a lot of wires I strongly urge that you consider using them. When I first setup a number of devices in a new entertainment center, when we moved into the apartment, I only used cable ties on a few devices and I regretted it ever since.

More recently, when moving to a new entertainment center, I decided that I would use cable-ties on everything, and I’m already glad that I did. Trying to route new cables can quickly become a chore when they get hung up on other cables and you’re having to feel your way through the various problems.

The Velcro Brand One Wrap Thin Ties I had purchased, from Amazon.com, of course, worked perfectly for this job. It has 100 ties rolled together. I used a large number of these on the latest project that involved pulling everything out of one entertainment center and setting those devices up in a new one…

Admittedly, I used them only after being unable to find them, stealing a bunch of cable ties from rolled up cables in storage, and then stumbling upon them later, about two-thirds of the way through finishing this project.

Just do it. Yes, it’s a pain. Yes, it might add a good half-hour or more to setting up your electronics, but… it… is… worth… it. This is a case of where a little bit of extra work on the front-end will save you a significant amount of time and frustration down the road.

But think it through a little. For example, I primarily used the cable ties simply to tidy up excess cable length. There were very few cases where I actually tied different cables together because doing that can actually make it a pain to remove a single cable down the road.

I’m sure you can find better deals with a higher volume of cable ties, but this particular set worked great for my needs.

Correcting RGB Color Value Scales for FLUX LED Strip plugin devices in Indigo – Python Scripting

Standard

I ran into a very frustrating problem last night while trying to work on some scripting within Indigo for controlling the LED colors of a new LED strip. I had no problem with actually controlling colors using the built-in UI tools for updating colors, but a slightly more complex usage presented a major problem.

The issue started with a need to save the current state of the individual RGB values in the LED strip, before I apply a change, such as when a notification occurs. This is to ensure that after a notification “flash” occurs that the colors will go back to the same values they were before the notification.

Via scripting, I had no problem getting the values. The problem occured when I went to restore the values. As it turns out, I struggled with this issue most of the night until I finally figured out that it was a difference between how the UI treats RGB values and how they are actually stored in the device.

The problem is that I was retrieving RGB values that were based on a scale with a minimum of 0 and a maximum of 255, but when I passed these values back the UI was converting those numbers, incorrectly, into values on a scale of 0 to 100. Eventually, I realized that before I can restore the individual color values, I must first convert them to the UI’s scale.

In addition, and perhaps I confused this with that issue, before I figured it out, I also had problems changing the color more than once in the same script. This may have been more of a timing issue (a kind of race condition) so I split the two scripts into seperate actions with a 5 second dely for the second script.

Here’s the first script that reads the LED strip’s color values and stores them into Indigo variables. The last line changes the RGB settings to display a yellow color, for notifications.

dev = indigo.devices[1681458792]
indigo.variable.updateValue(indigo.variables[872936515],value=unicode(int(dev.redLevel)))
indigo.variable.updateValue(indigo.variables[770189775], value=unicode(int(dev.greenLevel)))
indigo.variable.updateValue(indigo.variables[753658911], value=unicode(int(dev.blueLevel)))
indigo.variable.updateValue(indigo.variables[1059165341], value=unicode(int(dev.brightness)))
indigo.dimmer.setColorLevels(dev, 100, 100, 0, 0)

The first ID used represents the Indigo ID for the LED strip. The other four IDs are for the Indigo variables. All of these devices are unique to my Indigo setup, my devices and my variables. The correct values can easily be acquired by right-clicking (or Control-click) on the item within Indigo to select the ‘Copy ID’ option.

The next part of the script restores the value of the individual color variables. It first converts each value to an integer (all Indigo variables are stored as strings, so they must be converted for this type of usage) and then do some simple math to convert the RGB values to the appropriate scale. The original equation I found had more components but I removed them since the minimum value in both scales is always zero; by removing the zeros it had no effect on the final calculation.

Note that RGB values being set should be integers as well, before being used to actually change the color values.

dev = indigo.devices[1681458792]
valRed = ((int(indigo.variables[872936515].value) * 100) / 255)
valGreen = ((int(indigo.variables[770189775].value) * 100) / 255)
valBlue = ((int(indigo.variables[753658911].value) * 100) / 255)
indigo.dimmer.setColorLevels(dev, int(valRed), int(valGreen), int(valBlue), 0)

So far, this seems to be working properly.