With 0.942 having completed a week uptime (which may not seem much but is a good indication of stability) there are only a couple of minor things to check, the main one to see the max sensor limit on a single pin, and then I'll do a code release. 0.946 has been released without this final test - see below.
Latest release is 0.947 which supports the 23K256 SRAM and the FM25256 FRAM without code change. Note, you'll need to modify the V5 board to provide battery backup to the SRAM and use 3V3 overall. The easiest way to do the BB mod is to remove the HOLD resistor and cut the track to pin 8 of the 23K256. Use an 0603/0805 10K SMD resistor between pins 8 and 7 (I have to say I don't quite understand the aversion to SMD components and why they didn't use SMD anyway) and a Schottky diode across the track cut - very similar to the 5V mod below. This shouldn't be required for later boards but since I don't have one of the Nanode Classic this code hasn't been tested yet.
0.952 is a major re-write to use the Ethercard library. A few extensions were added to Ethercard to make it more useful for UDP broadcasts.
Work is now underway on a DMX<->xAP bridge.
The original One Wire interface for the Dallas DS18B20 devices (Temperature Sensors) was the TOM 10 board and a xAP Framework interface. However, this needed updating to xAP 1.3 and it was also felt that it would be good to reduce the reliance upon the PC for input devices - allowing for future stand alone BSC mappers.
Just recently there have been a number of small Ethernet enabled boards become available, together with a growing developer community. These are, to a greater or lesser extent, based on the Arduino platform. One such board, the Hackspace Nanode, seemed a good fit for redevelopment of the temperature sensing functions. The board has space for both a unique MAC address chip and an EEPROM/RAM. In this case a FRAM (FM25256) is used which requires +5V and the board requires a simple track cut and a link.
Since this is a board, configuration (a bugbear in xAP) is done via a web interface rather than an XML file used in the PC version. The UID and instance name can be configured here, as well as changing from numeric source sub-addresses to friendly names, so mmwave.bsctemp.house:lounge rather than mmwave.bsctemp.house:0001 All of these details are held in the FRAM. The software supports adding new sensors and these are placed in the FRAM in a logical sequence such that subaddresses don't change. Deletion is not currently possible, though a clean start is by disconnecting all devices and resetting the board.
The connection of the board to the sensors is straightforward with a single pull up resistor and using the devices in active mode.
The code takes about 25Kb and all the CPU RAM. There was enough space to include a small xAP logo on the webpage, though sadly it couldn't be any bigger due to the size of the ethernet packet buffer!
The homepage with the device information. V0.94 up has the device uptime on this page.
The device configuration page which allows the Source, UID and delta value that the temperature must change to generate the BSCEvent.
This is the subaddress/node configuration page. It allows the friendly name to be set and the setpoint value which controls whether the device sends a state=on or state=off in the message body. V0.94 up, the xAP message body includes the one wire address in the message body - this helps with sensor identification in a larger network.
The code is loosely based on the HAH work. Changes were made to the xapether
library and moved to Ethershield (something which may be changed back to
Ethercard). The xap class was extended to include full address matching and
setters/getters for UID and SOURCE.
The previous heartbeat implementation relied upon incoming traffic to generate
the heartbeat. This now uses a Timer 2 scheduler. This also schedules the
updates from the sensors.
A compile time option allows for the inclusion of the FRAM (or EEPROM/SpiRAM),
so it can run with a limited number of sensors without the FRAM - you do lose
all the web setup though as it would only be transient. The first 4 bytes of the
FRAM, etc., contain a signature to indicate it has been configured.
The FRAM implements a mini filing system for the sensor arrays and they are
stored by Dallas device address. To add a device requires only a reset and it
will be picked up and, if not used before, will be added to the end of the array
- the index being the subaddress. To clear the setup, disconnect the sensors and
reset the board. Certain future code changes, if they affect the file system,
may require a clean start.
Another compile time option allows for xAP 1.2 or xAP 1.3.
Full DHCP is supported. V0.94 automatically renews the DHCP address every 24hrs.
The code has been moved to Arduino IDE 1.0
The code has been moved to the Ethercard libraary with some custom extensions to
that library.
Limited information is presented on the serial port, including IP address, MAC address and number of sensors found.
The release 0.952 source code can now be downloaded from github git@github.com:g8kmh/Home-Automation.git Please be aware I cannot guarantee to answer your questions, so this is unsupported code.
There's also a copy of my 23K256 SRAM test code for the Nanode (AVR Atmega328) using SPI. I found that much of the code on the net was either plain wrong or didn't produce a result which actually verified it was working. And, unless you deselect the Ethernet chip the SPI reads are corrupted. https://github.com/g8kmh/Useful-Stuff-Arduino
git@github.com:g8kmh/Useful-Stuff-Arduino.git