search for: item_t

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to propose an interface change/extension, in order to be able to clearly differ from a PRE_SEND and a POST_RECEIVE item_t->preprocess-ing calls. IMHO there is no option to differ from item->preprocess(..), called from [1] and called from [2], at the moment. My idea is to extend the item_t->preprocess(..) with an additional argument about the calling point of the method like this [3]. The changes in the main...

Hi and thank you for your effort. You are very close to what I want to achieve, but I was already aware of the impossibility of querying direct from a command. I wanted the following (both would be covered by your changes): 1. preprocess an item_t in the direction: NUT->DEVICE in order to be able to support queries like ups.generated.yesterday ("QED<date-1><Checksum>\r") and ups.generated.today (note: today's generated power is even more complicated because it can't be queried due to QED<date>,...

mmh.. At the moment there are 3 distinct preprocess functions that operate on 2 different types: - info_rw_t - preprocess(); - item_t - preprocess(); - item_t - preprocess_answer(). For info_rw_t: range/enum values are preprocessed just to see if that specific value is to be used or not depending on the conditions the driver meets at runtime (e.g.: low voltage devices -> low voltage ranges). So, in this case, directions don...

Hi, I tested nutdrv_qx additions, introduced by @zykh, for a couple of months now and changed only small things. You can reach the repository via [1]. Please review the item_t array (starting at [2]) and give me feedback, or change it directly. Missing is the complete documentation, which I'm trying to get time for since the last six months, but I don't. Best, Nick [1] https://github.com/nickma82/nut/tree/nutdrv_qx_voltronic-sunny_rebased+command [2] https://gi...