State/Attributes confusion

[franc]

Hi,

I'm writing a module for a Wifi Kettle and have realised that I don;t really understand when to use 'state' and when to use 'attributes' properly.

The Kettle has two things you can do to it:-

* Set it's target temperature
* Set how long it will keep warm for

In the iKettle_Set function I handle 'Temperature' and 'Warm' and these will control the kettle properly. However I'm having trouble getting these to be reflected back in the GUI properly.

Any hints or pointers to how to get this to work ?

thanks

[rudolfkoenig]

There are following data classes in a typical FHEM Module:

- Internals: variables needed for the operation of a module, e.g. FileDescriptor, parsed(!) definition, last received data in Raw format, etc. Will not be saved, and cannot be changed (easily) by the end user. E.g. $defs{devName}{FD}, seen as $hash->{FD} in module functions.

- Readings: data delivered by the device you control, e.g. temperature or humidity, in human readable format. Always has a timestamp associated with it. It will be saved to the state file automatically at shutdown or save, and a change of the reading normally generates a FHEM event which can be logged or reacted upon by end-user via notify. It is not supposed to be changed by the user. It is set by the readingsSingleUpdate/readingsBulkUpdate functions. Stored as $defs{devName}{READINGS}{readingName}{VAL}, but use ReadingsVal() to access it if you are not experienced.

- Attributes: FHEM-Device-Instance properties, which should only set by the user (not by the module-developer), e.g. room/group, disabled flag, etc. Will be saved together with the definition in the fhem.cfg only if the user calls save. Stored in $attr{devName}{attrName}, but use AttrVal to access it if your are not experienced.

state is a special reading, which should contain all the data the developer finds useful to be seen in the overview, e.g. "T: 12.0  H: 45" for a combined temperature and humidity sensor. The STATE internal is normally a copy of this state reading, but it can be overridden by the end user via stateFormat, e.g. if he finds the humidity irrelevant in his setup. This STATE is displayed in the room-Overview, or if you call list without argument.

In your case the mentioned interface is not ideal, and I am not sure if I would store the data as an attribute or offer it as a set command and store the argument in a reading. The default WEB frontend (FHEMWEB) allows attributes only to be changed from the detail page, set commands can be configured to appear on the room-overview, but not on the mobile variant.


Can you tell me the name of this product?

[franc]

The Kettle is this one:- http://www.wifikettle.com/

The protocol to describe it is described here:- http://www.awe.com/mark/blog/20140223.html

Any suggestions you have would be appreciated

cheers

[rudolfkoenig]

Any suggestions you have would be appreciated

I would open Port 2000 with DevIo_OpenDev, and define a ReadFn to handle events. Since one port corresponds to one device, there is no need for the more complex two-FHEM-modules approach, and you can generate your events via readingsBulkUpdate directly, not needing Dispatch.
I would go with the set approach outlined before, offering the commands on,off,100c,... and storing only those commands in readings, which are stored by the kettle too, e.g. 100c, etc, but not on and off.

[franc]

I think I follow that for reading information from the kettle, but what about in iKettle_Set(), should I be updating the STATE or updating the attributes ?

thanks

[rudolfkoenig]

If you read my sermon from before carefully, you'll see that a module should not change attributes, only readings (and internals).
STATE is taboo too, just change "state" via readingsBulkUpdate.