working notes file device_classes_branch.txt moved over to an issue

Fork: 0

alex / pyenergenie

Browse code working notes file device_classes_branch.txt moved over to an issue master
1 parent 6afd25e commit 419bb89851530a0c8e93dd874f5c33bb447a3e25 David Whale authored on 30 May 2016

Patch

Unified Split

Showing 1 changed file

                Show notes
              View
            
          
          92 ■■■■■
          doc/devices_classes_branch.txt
        
        
          100644 → 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
-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

Show line notes below