I recently bought an Insteon irrigation controller called the EZFlora. In this article, I will describe how the controller works and how to use it from scratch with a PLM. I am not using any well-known software to control my Insteon devices. This information is usefull for people building their own software and communicate directly with the PLM . Before going any further, basic knowledge of how to send standard and extended commands to a PLM is required. This is part of my Home Automation system. You can find an example source code in that Home Automation system article.
The EZFlora is a 8 zone irrigation controller. It allows me to control up to 8 solenoid valves for my garden. The EZFlora lets you open/close a valve or run a program. A program is a sequence of timers. It is possible to make 4 different sequences. A sequence is represented internally by an array of 8 bytes that represents the runtime in minutes of each valve. Byte 0 is for valve 0, byte 1 is for valve 1 etc. Programs are very usefull because your application sends a command to start a program (sequence) and just waits for the results. If your application would open a valve and for some reason the application crashed, hung or communication with EZFlora would go down (or any other reasons), then you could not send a "valve off" message. With a program, you leave it to the EZFlora to do everything. An application "uploads" such programs by sending the "set sprinkler timers" extended command. CMD1 is 0x40, CMD2 is the program number (0-4) and the first 8 extended bytes represent the sequence. Note that this will store the program into eeprom. The program numbers are from 1 to 4. Program number 0 is the default timers. Default timers are used when a valve is opened with the "valve open" command. After the timeout expires, the valve will close. This is usefull in case you would forget to close the valve.
My server initially sends a "sprinkler control" command to enable valve status messages. These messages are broadcast messages. The annoying thing is that the PLM will not forward those events to your application. So my server needed to put the PLM in "monitor mode" using command 0x6B (see the 2412 Dev guide). It is really important that you do this, otherwise you will not receive any of the broadcast events. The EZFlora also needs to be in the PLM's All-Link database.
One nice thing is that any "sprinkler control" command sent, will return a status byte in the ACK message. So by sending such a command, I am also requesting the system status indirectly. Now every time a valve status changes, I will also receive a message that contains the status byte. The status byte tells me what valve is currently opened and what program is running (if any). As the command set document indicates, the status event broadcast message also contains the water meter counter hidden in the "To Address". So bascially, when I send a command to start a program, I get the valve/program status in the ACK message. Then everytime the program activates another valve, I get a broadcasted message with the valve/program status and the meter counter value. And the end of the program, I can see in the event that the program is not running anymore and using the meter counter I know how much water was used during the whole program. Note that when a program turns off a valve and opens the next one, it broadcasts only one event with the newly opened valve number. This is fine since the EZFlora always activates one zone at a time. So when you see that valve X is opened, it is safe to assume that all other valves are closed.
Water meter counter It is possible to attach a water meter counter to the EZFlora and get events every time the meter makes a pulse. The meter I was looking at generates 450 pulses per liters. That would generate way too much traffic. So I decided to leave the "Meter count change" event off. Instead, I reset the counter everytime I send a start valve or start program command. And I look at the meter count every time I get a status message. When I get a status message that says that no program is running, I can deduce that it was because a program has terminated so I check the meter count and I know how much water I used while the program was running.