diff --git a/doc/devices_classes_branch.txt b/doc/devices_classes_branch.txt
deleted file mode 100644
index 1ca57e3..0000000
--- a/doc/devices_classes_branch.txt
+++ /dev/null
@@ -1,91 +0,0 @@
-
-HMM? 2. NAME REGISTRY: To be able to build a local registry of devices and their configurations,
-   and refer to devices by name inside the application.
-
-   HMM? e. the registry can be queried, such as 'find me all devices that are of
-      type x' or 'find me all devices in location kitchen'.
-
-
-HMM? 3. INTENTS: To be able to command and query devices in a way that represents
-   POSSIBLE b. the last receipt time of data from a transmitting device to be known
-
-   POSSIBLY c. the next expected receipt time of data from a transmitting device to be known
-
-   POSSIBLY d. the last known state of a transmitting device to be known (e.g. switch state
-      both by commanded state and retrieved state)
-
-
-HMM? 7. PERFORMING: To be able to build a well performing system
-   with very few message collisions and message losses
-
-   POSSIBLE a. by dynamically learning report patterns of MiHome devices
-
-   POSSIBLE b. by intelligently deferring and schedulling transmit messages
-      to avoid transmit slots of reporting devices
-
-   POSSIBLE c. to query device characteristics such as modulation scheme and msg repeats.
-      also to estimate the transmit time of a particular message to help
-      with message scheduling.
-
-
-DESIGN Devices.py
-
-remaining items to investigate:
-
-  commanded state? (did we ask it to be on, when did we ask?)
-  reported state? (did it tell us it is on, when did we learn it?)
-
-  overall device state
-    have we seen this device this run?
-    when did we last hear from it?
-    when did we last talk to it?
-    when do we expect to next hear from it?
-
-  yet unmodelled devices still to be usable to some degree
-    for MiHome devices, a proxy class generated dynamically based on received message parameters.
-    e.g. if it reports a TEMPERATURE field, then there should be an automatic get_temperature() method
-    generated.
-
-  possibly add callbacks such as when_turned_on() when_turned_off() etc.
-
-(do we need to know what our last sent request is, vs last known reported state?
-e.g. if we have sent a request but not heard a response yet, this means we think we asked
-it to turn on, but we don't yet know if it has done that. Some devices can't report
-back, but some can, so it would be nice to have a four stage state machine for on/off)
-
-(note, would be good to be able to persist the last message received on disk,
-so that when code restarts, it knows the last send/receive time that was last processed.
-i.e. a resumable state machine persisted to disk)
-
-(note, a message scheduler if inserted in the middle, would do callbacks to say
-that the request has been processed, so timestamps can be updated. Also same scheduler
-could handle retries perhaps, if the device is tx and rx, then when you send a switch
-change, it would normally report back that the switch had changed, so if you don't
-get it, or if it is in the wrong state, could retry a send again until it changes)
-
-(note, inner variables might have two versions for some devices, the requested
-value and the confirmed value. If they are different, it means might still be
-waiting for a reply, so can't guarantee the command was received yet)
-
-POSSIBLE: 9. understand read only and read/write intents better
-
-   when using configuration data and last known values, it is useful
-   to keep them in the same single file, so it is easy to copy
-   to other machines. Some data is naturally 'write once' and
-   very configuration based. Some data is naturally 'write often'.
-   It might be nice if these two types of data could appear in the same
-   file, but the locking/performance and resilience issues be handled
-   differently for the two classes of data - e.g. perhaps having
-   two connections to the same database file, one in read only mode
-   for config records, and one in read/write mode for last use data.
-   There might also be different namespace prefixes in the file
-   so that the key sets are separate, or there may be a way to
-   link them so that when you read a record you get both the static
-   config data and the fast changing last use data as a single
-   record. But this then implies when you do an update, you
-   probably want to update part of a record rather than the
-   whole record.
-
-
-Note: callbacks on when_updated() might be required
-