{"action":"created","issue":{"url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/18","repository_url":"https://api.github.com/repos/whaleygeek/pyenergenie","labels_url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/18/labels{/name}","comments_url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/18/comments","events_url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/18/events","html_url":"https://github.com/whaleygeek/pyenergenie/issues/18","id":111343709,"number":18,"title":"Modelling devices as classes","user":{"login":"whaleygeek","id":4086785,"avatar_url":"https://avatars.githubusercontent.com/u/4086785?v=3","gravatar_id":"","url":"https://api.github.com/users/whaleygeek","html_url":"https://github.com/whaleygeek","followers_url":"https://api.github.com/users/whaleygeek/followers","following_url":"https://api.github.com/users/whaleygeek/following{/other_user}","gists_url":"https://api.github.com/users/whaleygeek/gists{/gist_id}","starred_url":"https://api.github.com/users/whaleygeek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/whaleygeek/subscriptions","organizations_url":"https://api.github.com/users/whaleygeek/orgs","repos_url":"https://api.github.com/users/whaleygeek/repos","events_url":"https://api.github.com/users/whaleygeek/events{/privacy}","received_events_url":"https://api.github.com/users/whaleygeek/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":20,"created_at":"2015-10-14T07:54:47Z","updated_at":"2016-05-29T14:58:40Z","closed_at":null,"body":"Initial Proposal for modelling devices as classes.\r\n\r\nThe purpose is to be able to write expressive and compact applications that talk in the land of physical devices such as 'myRadiator' and 'myPlug' or even second level names such as 'myKettle' (which is plugged into 'myPlug'). Thus hiding the detail of how messages get encoded and transported, and focusing an application more on it's intents than on it's implementation.\r\n\r\n* each different device has a class 'cookie cutter' (e.g. Energenie.MiHomeAdaptorPlus(),Energenie.eTRV())\r\n\r\n* each instance of a device is an object (e.g. plug, rad...)\r\n\r\n* each device instance can be named and abstracted as appropriate to it's purpose (e.g. kitchenKettle(plug), hallwayRad(rad))\r\n\r\n* Outgoing command messages modelled by function calls and/or properties (e.g. kitchenPlug.turnOn() or even kettle.turnOn()...)\r\n\r\n* Incoming data modelled by function call getters and/or properties, perhaps with a cache of the last received value (e.g. hallRad.getTemperature(), hallRad.temperature)\r\n\r\n* meta-model driven proxy classes for device types not in the device dictionary (e.g. an unknown device sends it's temperature, so you can still say unknownDevice.getTemperature() or unknownDevice.temperature)\r\n\r\n* a low dependency link from the device object instances to the transport that sends and receives messages on their behalf (e.g. kitchenPlug = Energenie.MiHomeAdaptorPlus(OpenHEMS(myRadio))\r\n\r\n* an outwards link via OpenHEMS(radio) for queueing transmit messages. An inwards link from OpenHEMS(radio) back to the object, so that when a message is received from a specific (mfrid, prodid, sensorid) the data is routed to the correct object instance.\r\n\r\n* perhaps a catch-all object that receives messages from unknown or unregistered devices, with a way to later morph those into real device instances (e.g. this could be how the discovery service is created, by all messages for unknown sensorid's going to a catch all, and later the app constructing appropriate object abstractions around them and them being removed from 'unknown'\r\n"},"comment":{"url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/comments/222365031","html_url":"https://github.com/whaleygeek/pyenergenie/issues/18#issuecomment-222365031","issue_url":"https://api.github.com/repos/whaleygeek/pyenergenie/issues/18","id":222365031,"user":{"login":"whaleygeek","id":4086785,"avatar_url":"https://avatars.githubusercontent.com/u/4086785?v=3","gravatar_id":"","url":"https://api.github.com/users/whaleygeek","html_url":"https://github.com/whaleygeek","followers_url":"https://api.github.com/users/whaleygeek/followers","following_url":"https://api.github.com/users/whaleygeek/following{/other_user}","gists_url":"https://api.github.com/users/whaleygeek/gists{/gist_id}","starred_url":"https://api.github.com/users/whaleygeek/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/whaleygeek/subscriptions","organizations_url":"https://api.github.com/users/whaleygeek/orgs","repos_url":"https://api.github.com/users/whaleygeek/repos","events_url":"https://api.github.com/users/whaleygeek/events{/privacy}","received_events_url":"https://api.github.com/users/whaleygeek/received_events","type":"User","site_admin":false},"created_at":"2016-05-29T14:58:40Z","updated_at":"2016-05-29T14:58:40Z","body":"@iotic-labs-markwharton please review the discovery functionality described in #56 and in the code on the device_classes branch in setup_tool.py and discover_mihome.py, as I slotted this in with this work especially for you. If you could report back any observations in issue #56 that will be helpful, thanks.\r\n"}}
{"actor":{"display_login":"whaleygeek"}}