en-us Tiki RSS feed for blogs Last posts to weblogs. http://stovenour.net/img/tiki/Tiki_WCG.png Feed logo http://stovenour.net/ Thu, 16 Apr 2026 22:28:27 +0000 Zend_Feed_Writer 2 (http://framework.zend.com) http://stovenour.net/ Pool Fill: Debugging ESP8266 with no serial port should ignore it as garbage. (note to self: make sure command library can detect garbage) There is a solution using a second serial port on the ESP8266, but it is only one way because the RX pin can not be used. I would also need to make an adapter for my FTDI cable. Then I had an idea; why not just publish an MQTT debug topic? It seems like this might be handy even after development is done for debugging live issues. I planned to add MQTT support regardless so it should be relatively easy to add another topic.
  1. Research and install MQTT broker on local LAN
  2. Configure the MQTT Arduino client
  3. Add MQTT configuration parameters to the web configuration screen

]]> Sat, 25 Feb 2017 15:03:00 +0000 http://stovenour.net/blogpost121-Pool-Fill-Debugging-ESP8266-with-no-serial-port http://stovenour.net/blogpost121-Pool-Fill-Debugging-ESP8266-with-no-serial-port 0 Pool Fill: SNTP Client
  • Always operate the software in either UTC or local standard time; apply DST shifts when viewing or setting the schedule and clock
For the controller I plan to always operate it in local standard time because again testing and debugging the scheduler where local time and UTC can be +/- 12 hours seemed like way too much work. This also means that the controller does not need to be told the timezone or timezone offset. It only needs to be told about the DST offset (0 or some positive integer minutes). The user will always interact with the controller in local time (DST or ST). The controller will store and schedule set points in standard time. For the user this is all as one would expect except for one effect. The previously scheduled entries will shift an hour at the DST shift. This is no worse than a controller that doesn't accommodate DST at all and a big improvement when the user is trying to set the schedule.
For the web server I plan to always operate it in UTC. The user will need to set a timezone with offset from UTC and DST start /end data (all the timezone data for the Timezone.h library). That should be relatively easy with the web interface. Timezone information is needed regardless since the SNTP client only receives UTC and must be offset for local time. Handling DST shifts on the Web Server are trivial since there is no scheduling logic. Again the internals will all use UTC and will be offset to local time when interacting with the user.

Some fun facts I learned along the way:
  • The DST begin and end points vary all over the world and have changed many times in history; even in recent history. The shift has not and is not always 60 minutes; even today at least one country (Australia) has a region using 30 minutes
  • The ESP8266 internal SNTP client can be set for timezone and automatically adjust for DST; however the DST shift points are fixed to align with some undocumented region, making the capability practically useless
]]> Thu, 16 Feb 2017 14:43:00 +0000 http://stovenour.net/blogpost120-Pool-Fill-SNTP-Client http://stovenour.net/blogpost120-Pool-Fill-SNTP-Client 0 Pool Fill: SNTP Client
  1. controller needs to be told the current local time shift (including DST)
  2. controller needs to shift all interactions with the user
  3. does the controller store set points in localtime or UTC?
]]> Mon, 13 Feb 2017 14:42:00 +0000 http://stovenour.net/blogpost119-Pool-Fill-SNTP-Client http://stovenour.net/blogpost119-Pool-Fill-SNTP-Client 0 Pool Fill: SNTP Client Arduino millis() function for checking elapsed time! See this for an overview of timing best practices: How can I handle the millis() rollover?

Need to debug the scheduler for days past sunday. Found a real doozie of an error and corrected it but the fix is untested.

Always set the clock to a date past 1/1/1971 or the schedule timing functions will not work correctly. The best thing here is to force the clock to something like 1/1/2017 at startup; then free run from there until something sets the time.

Need code to handle inhibit > unix epoc rollover; also scheduling for the week following the unix epoc rollover needs to be studied.

On a DST spring forward; anything scheduled between 2am and 3am will be skipped.
On a DST fall back; anything scheduled between 1am and 2am will be scheduled twice.

remainingRunTime will also break across the shift

]]> Sun, 12 Feb 2017 14:40:00 +0000 http://stovenour.net/blogpost118-Pool-Fill-SNTP-Client http://stovenour.net/blogpost118-Pool-Fill-SNTP-Client 0 Pool Fill: SNTP Client NTP libraries for Arduino. None of them are actually NTP. All of them are SNTP but probably not even fully SNTP compliant.

Need to combine:
  • TimeLib
  • Arduino Timezone Library
  • ESP Library time.h (includes sntp.h)

  1. Need to work out the linkage between Arduino time library and the ESP time library
  2. Need to work out the linkage between the Timezone Library and the ESP time library
    • It seems that the ESP time library uses some fixed DST start/end values....
  3. Need a prototype for testing
]]> Fri, 03 Feb 2017 14:33:00 +0000 http://stovenour.net/blogpost117-Pool-Fill-SNTP-Client http://stovenour.net/blogpost117-Pool-Fill-SNTP-Client 0 Updating Spamassassin http://blog.exeko.com/2008/05/30/update-clamav-daemon-on-debian-etch/



]]> Sun, 09 Nov 2008 14:07:25 +0000 http://stovenour.net/blogpost60-Updating-Spamassassin http://stovenour.net/blogpost60-Updating-Spamassassin 0 Annual bluegrass
Annual bluegrass, Poa annua

It looks like short of hiring a professional to use some of the specialized chemicals, I need to:
  1. Concentrate on fall pre-emergent control; I think I'm generally too late for this one. I'll try to get it out in early September this year. Most references say that germination starts at soil temperatures of 70 degrees.
  2. Physically remove the weed

I think it is edging out the bermudagrass. Then in the middle of summer, when the bluegrass dies, the weeds like oxalias take off. Once the other weeds are established the bermudagrass has a hard time competing.
]]> Sun, 30 Mar 2008 05:18:37 +0000 http://stovenour.net/blogpost54-Annual-bluegrass http://stovenour.net/blogpost54-Annual-bluegrass 0 Web and Mail Server Log Reports
AWStats

]]> Sat, 22 Mar 2008 17:21:59 +0000 http://stovenour.net/blogpost53-Web-and-Mail-Server-Log-Reports http://stovenour.net/blogpost53-Web-and-Mail-Server-Log-Reports 0 Adding anonymous contact capability
Let the spammers loose! I'm hiding behind my desk now.
]]> Fri, 07 Dec 2007 22:39:18 +0000 http://stovenour.net/blogpost50-Adding-anonymous-contact-capability http://stovenour.net/blogpost50-Adding-anonymous-contact-capability 0 Why I can't program my VCR
A couple of years ago I purchased an X-10 based home control bundle. X-10 modules are simple devices that allow control over lights and other electric items in the home. I purchased a bundle that came with computer software for scheduling control. Initially I wanted to control my Christmas lights. I thought it would be nice to have the lights scheduled to come on at dusk and go off at midnight. Well... Three years later, I have six accent lamps in my home on two different zones plus the outdoor Christmas light circuit all on X-10. But I can't even tell you where I put the computer software. That interface was well, just too inconvenient. I use a tiny wireless remote with two buttons; two zones, on-off; that's it. No timers, nothing fancy; it's just easier that way.

A well written research thesis from the University of Maryland, Protocol and Interface for Device Control in the Home Environment, points out that our inability to learn each device and more recently our inability to coordinate multiple devices is a direct consequence of device centric user interface design where every device has a unique interface. These interfaces tend to be excellent when they get it right (e.g. TiVo) and horrible when they do not (e.g. my sprinkler timer). There is very little in between.

This quote from the paper illustrates the point.
devices feature their own unique interface that forces users to relearn the same tasks anew for every device. Devices also lack the ability to be coordinated; the only interface most devices offer is a set of buttons and a remote control. This egocentricity inherently limits a user’s ability to orchestrate and manipulate their devices; the device presumes it knows every way it would want to be used.


Ok, so I need to schedule my X-10 lights, DVR, VCR, sprinklers, and while we are at it my HVAC. Scheduling is somewhat the same, pick a time to start, pick a time to stop... Ok, recording live broadcasts requires access to schedule information, but a device that gets that right (i.e. TiVo) could surely get the others right. Right? Well, no; as it turns out none of those devices are capable of talking to each other. Why? Because each manufacturer is only interested in their own user interface.

Let me stop for a second and dispel what I believe is a myth. Some might say the reason all of these devices can not talk to each other is cost. After all it is more expensive to imbed radio links or install wired interfaces. Well, when I see people shelling out $1500+ for a TV, yes a flat panel, I can't help but think that there are plenty of folks out there that have the cash. They just don't want home automation; at least not the kind that we've all been building for them.

Solution

Separate the device interface from the device and use common interfaces for all similar items in the home.

If TiVo is great at building user interfaces then they could become THE user interface for the home. But clearly TiVo can not build all devices for the home so they need some way to communicate with all the devices in the home. This requires an open communication bus that is independent of the physical layer it runs on (e.g. Ethernet, wireless, power line carrier, etc.) but that supports auto detection and auto configuration.

In this model, I envision two industries; those that compete for the user interface and those that compete for the devices.

What protocol you ask? I believe something simpler than UPnP maybe like xPL.

]]> Mon, 18 Dec 2006 15:18:20 +0000 http://stovenour.net/blogpost19-Why-I-can-t-program-my-VCR http://stovenour.net/blogpost19-Why-I-can-t-program-my-VCR 0