Sunday, December 15, 2019

65: Measuring Kilowatt Hours *

I recently bought a plug-in hybrid Kia Niro. I was surprised to find out that while I could schedule when the car would charge and could modify that schedule from a phone app, nothing told me exactly how many kWh of power I was using. I kind of expected that the electric miles would be much cheaper than gas miles but I wanted to know exactly. The battery is supposedly 9.7 kWh. When fully charged, the dashboard display shows me that I have 24 electric miles. That's about right on the highway but around town and on 2-lane roads I get more like 30. Anyway, not finding what I wanted and having a spare Photon, I built the following (with necessary engineering help):

Outside                              Inside   

Sensor – power wire through the hole

The sensor is called a "current indicator." The serious programming is in the Photon. A proto program allowed us to plot the relationship of raw analog sensor values to Watts -- turned out to be a nice straight line. I tested my laptop 45w power charger, a 75w bulb, a 800w toaster and a 1200w clothing iron. The real program takes 40 current samples (1 ms apart) each minute. The maximum value is added to a sum for the hour. The sums for the latest 24 hours are copied to a Particle "variable". That variable is read by a Raspberry Pi -- which produces a summary like this (via a simple PHP program):

    Hr 16: 0.16
    Hr 17: 1.39
    Hr 18: 1.4
    Hr 19: 1.39
    Hr 20: 1.39
    Hr 21: 1.39
    Hr 22: 1.39
    Hr 23: 0.68

    Sat 12/14  kWh: 9.26, cost: $0.83


Michigan Consumers Energy kWh rates for electric vehicles
Oct thru May -- Off peak: .090, On: .103
Jun thru Sep -- Off peak: .085, On: .123

Peak hours: 11:00 up to 19:00

The record above runs from 4pm till midnight for December 14. So I'm paying nearly 3.5 cents per electric mile. At my local $2.60-ish gas per gallon and the Kia's 45 mpg in hybrid mode (under 6 cents per mile) I'm not saving a lot. Gas should be way more expensive. Of course, I only stand out in the cold to pump gas once every 900 miles. 

 I will be accumulating data and will update this page.

* 12/20: Turned out that the Photon interfered with my wireless garage door buttons. Moved it 15 feet away and to different circuit -- now works ok. But why? Very different wireless frequency.

Friday, June 21, 2019

64: Adding a WIFI Antenna to a Photon

I've been having trouble with Photons remaining connected to the cloud. This in a place where an iPhone is ok (1/2 bars). So I started recording signal strength with this line of code:

  int wf = WiFi.RSSI();

Note that if you don't assign the value to an int first it will be treated as unsigned in an sprintf function "%d". Bug!

Anyway, the signal values returned run like this: (good to poor strength range: 1 to –127)
  • -10 -- strong/right next to the modem,
  • up to -60 -- reliable signal,
  • up to -75 -- so-so,
  • over that -- unreliable.

According to Particle Docs, these STARTUP calls control antenna choices:

  //STARTUP(WiFi.selectAntenna(ANT_INTERNAL)); // selects the CHIP antenna, default?
 //STARTUP(WiFi.selectAntenna(ANT_EXTERNAL)); // selects the u.FL antenna
 //STARTUP(WiFi.selectAntenna(ANT_AUTO)); // only works with antenna attached?

Note those statements are all commented out because they seem ineffective. But the good news is that adding a simple/cheap antenna does work* -- to the tune of improving signal strength by 10 to 15.

Another Particle complaint: the Docs generally fail to specify default return values.

_________
* The tiny snap-on connector can be frustrating.

Tuesday, July 10, 2018

63: A Nasty Relay Board Insulation Problem

See my Raspberry Pi Blog post 118 (at dicks-raspberry-pi.blogspot.com). Seriously!

Wednesday, January 10, 2018

62: A Better Mousetrap (I mean breadboard)

Regardless of my resolve, my breadboards always end up a mess. And, if you've read my previous posts, you'll know I hate soldering. So I'm always looking for the secure but easier way to wire things. Here's my latest idea.

Imagine a breadboard where the pin holes on the normal top pass through to the mirror holes on the bottom (I tried with a current breadboard, but the metal row connectors get in the way).


Here's a rough sketch:
Anyway, with the mirrored breadboard, wiring can still be easily changed but the wires are protected. I'd be willing to pay a few extra $ for this breadboard.

Sunday, November 26, 2017

61: Hoop House Rollup Motors

I described this system back in post 56. I meant to get this done early in the summer but things got in the way. I had 4 hoops to do and would have preferred to just install one first to get the wrinkles out but because it was already September I did them all at once. And we got to experience the problems times 4.

Here's what the smartphone web page looks like at the moment:
                                                                                  
Hoop fmX Sidewalls:
9:50PM: Hoop Temp: 40°
Auto Temp: OFF
Motors: Left=DOWN, Right=DOWN
Weather: Temp: 38.8°, Wind: N 1.1 MPH

Change?
Auto Temp Mode: Turn ON

Both Sides: Roll UP

Left Side: Roll UP

Right Side: Roll UP

Stop Motor!

Reload Page
                                                                                  

Here's a pic of a motor and the 196' long rollup pipe:


In the web page: info above the word "Change" shows the current state of the system. If you click any of the next 4 items below that the wording will change accordingly.

Here are some of the problems I have run into:
1. We had to use WIFI extenders because of the distances involved. It took a few tries to get them placed properly.
2. Flakey Internet service caused me to add manual UP/DOWN buttons to the Photon system enclosures.
3. Two of the 4-port relays I use to switch the 24v DC between the wires to the motors have failed.
4. The ACS714 current sensors are a disappointment so far. The analog readings are inconsistent (as they are currently wired). This means that rollup/down operations have to use worst-case wait-times. Very irritating.
5. It turns out that the rotation settings on the motors have to be adjusted after a few up/down cycles. Perhaps because wrinkles in the plastic get smoothed out with the uniform running speed of the motors.
6. Adapting the motor shafts to the hoop rollup pipes was challenging.
7. Getting  "Auto Mode" to work properly was a trial. At first I had the auto UP temperature too close to the auto DOWN temperature. So, the sides roll up, temperature drops immediately and the sides roll back down; over and over. Placement of the temperature sensor is tricky and the UP/DOWN thresholds have to be over 15 degrees apart.
8. Local temperature and wind is boiled-down from wunderground.com for the zip code. It is updated every 15 minutes by a Raspberry Pi.
9. An Rpi running Particle-agent sends and receives messages (via publish/subscribe) from the Photon systems.

More to come.

Sunday, September 3, 2017

60: Particle Photon Esoteric Hints 
(must previously have installed particle-cli)

1. When your Photon is not ready to accept a new flash: If (as I do) sometimes purposely load a program that is meant to run without the cloud then you can have a problem when you need to flash new software -- because the Photon is not connected. The following info is in Particle Docs, but not all in one place.

a. To get back to "breathing cyan" so you can flash:

Hold down RESET and SETUP, release RESET and continue to hold down SETUP while the main status LED blinks magenta until it blinks yellow, then release.


b. Then load a sketch that exists as part of the particle-cli package. In Terminal app on Mac OS:

$ particle flash --usb tinker # Photon connected to USB (of course)

It's not that you want to use tinker. It's just harmless software that allows you to then flash your own code.

2. What if you want to set up a Photon for a wifi network that is elsewhere?

a. First, the device must be in "Listening Mode". To do this hold down the SETUP until the RGB LED blinks blue.

b. Of course the Photon must be plugged to a USB port. Here's the command:

$ particle setup --usb
(output back: blah, blah)
Claim code set. Now setting up Wi-Fi
...
Attempting to configure Wi-Fi on /dev/cu.XYZ
? SSID name-of-the-network
? Security Type WPA2 (selected, not typed)
? Cipher Type AES+TKIP (ditto)
? Wi-Fi Password your-pw
Done! Your device should now restart.
! It doesn't look like your Photon has made it to the cloud yet.
? What would you like to do? Check again to see if the Photon has connected
... (took a while)
> It looks like your Photon has made it happily to the cloud!

And so you've made it (with luck).

3. What about where several Photons are running the same program but you need to identify them individually? You could do this messily by using a C++ "#define" statement -- a 1 line source change for each Photon: pretty certain to lead to errors. A better way would be to get the Particle cloud to tell your program the device name that you gave the Photon. It would be nice if Particle provided a call like: "Particle.deviceName()" that returned the name as a char array. The good news is that you can get the name but it is not so straightforward. Here's code that works:

char DevName[20];
...
void getname(const char *topic, const char *data) {
    strcpy(DevName, data);
}

void setup() {
    ...
    Particle.subscribe("spark/device/name", getname);
    Particle.publish("spark/device/name");
    delay(5000); // DevName won't get filled in for several seconds
    ...
}

Note that while Particle lost use of the name "spark" a couple years ago they have never changed all of the sparks to particles. Not nice, Particle!

Wednesday, May 3, 2017

59: Particle Photon "Persistent Data"

Up till now I have handled the problem of getting data to persist between reboots by sending it daily to-and-from a Linux (Raspberry Pi) system. And I will continue to handle Daylight Savings that way. But now I'm going to try Particle's EEPROM memory storage scheme. The Photon provides 4096 bytes of flash RAM that presumably/seems-to persist between power outages. The hitch is that you have to manage storage space allocation on your own. So if you want to store a C++ int you have to know to offset the next variable by at least 4 bytes (higher number). Reminds me of my first assembly language compiler from 1961.

Here's a sample program.

#define VAR1 0 // first address in eeprom -- 32-bit int
#define VAR2 4 // leaving room for the previous value
int Var1;
int InitialValue = 123; // whatever...

void setup() {
EEPROM.get(VAR1, Var1); // copy from eeprom to RAM data
if(Var1 == -1) { // hex "FF"s first time, not initialized
   EEPROM.put(VAR1, InitialValue); // load starting value
   ...
}
 // might also want to check for reasonable "get" value!
}

void loop() {
// use or change eeprom values as needed
}

More/better info at--
https://docs.particle.io/guide/getting-started/intro/photon/
Search for "EEPROM".