Skip to content

Commit 0ee0351

Browse files
author
Jan C
committed
document autorepeat value function return value
1 parent 4508f54 commit 0ee0351

1 file changed

Lines changed: 4 additions & 2 deletions

File tree

docs/developer_guide.md

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -41,9 +41,11 @@ The meaning of the parameters of a button value function is:
4141
* descr: the entity description object of the button
4242
* datadict: the dictionary with all the known entity values
4343

44-
In its current form, the function should return a list that represents the payload of a write_multiple command that starts at the modbus register address of the button entity.
44+
In its current form, the function should return a dictionary containing following items:
45+
* action: the modbus type of write to be executed: currently only MODBUS_WRITE_MULTI is suppored, but the other writes can be easily added later.
46+
* register (optional): if not specified, the register address for the autorepeat button will be used
47+
* data: a list of tuples [ (entity_key, value,), ....] that represents the payload of a write_multiple command that starts at the modbus register addres. Instead of the entity_key_name, a register type can also be specified like REGISTER_U16. The payload should not contain the button's entity itself, just the data that needs to be added in the write_multiple scenario.
4548
In the future, the return value may be extended to allow other types of writes (to different addresses).
46-
The write_multiple list is a list of tuples [ (entity key name, entity value,), ... ]. Instead of the entity_key_name, a register type can also be specified like REGISTER_U16.
4749
The system will automatically compute the length of the write_multiple payload to be executed.
4850

4951
The autorepeat value_function is called once for every polling loop, so it is up to the value function to reduce the number of interactions if desired. Currently, the value_function cannot pass data to the next polling cycle's value_function's call. This could be enhanced as using global variables is not considered a best practice (may fail in case of multiple inverters/hubs). Storing this data in the descr._hub object may be better, but it is still not very transparent.

0 commit comments

Comments
 (0)