Hi Niky,
You will find attached my modifications to 3.12 dec 2023.
As a foreword:
All modifications are under compilation flags that start with
YGN. Today I have defined:
#define YGNCHECKDIFFMESSAGE //remove 2 identical consecutive received msg
#define YGNREDUCE_hp_time // in relation with above define reduce rstat_pkgs_hp_time
#define YGNEXTERNVARACCESS //allow to get acces to some FW variables (g_channels_...)
#define YGNSENDONLYONEPKT // faster zwave send data on average
#define YGNRESETBUSYQUEUE // reset queue if it stays too long 'busy'
#define YGNPROTECTEEPROMACCESS // delay Zwave traffic if EEprom is used & prevent eepromW if queue busy
#define YGNNO_EEPROMUSE //remove ZWCCBasic EEprom use
and main undefined:
#undef FULL_LOG // if undef, LOGGING_DBG is “simplified”
#undef YGNINCOMINGLOGS //To log also incoming messages
#undef YGNOUTGOINGLOGS //To log also outgoing messages
#undef YGNCHECKSYSCRITIC //add checkSystemCriticalStat stuff to compilation
#undef YGNLOGBUSYQUEUE //log 'stats' on busy queue state
#undef YGNINTERVALSTART //100ms spared after rstat_pkgs_hp_time
In the description that follows I have only explained modifications for which the flag is DEFINED…
In CommandQueue:
- YGNPROTECTEEPROMACCESS : Added a function to be called before EEPROM.put so that zunoCheckSystemQueueStatus() returns ‘true’ during 1sec. Efficiency : ???
- YGNRESETBUSYQUEUE: in zunoCheckSystemQueueStatus() if the queue is busy for too long (15s) do a reset Queue executing g_zuno_sys->rstat_priority_counts[channel] = 0; g_zuno_sys->rstat_pkgs_hp_time = 0;
This is probably not fair 
but it is really efficient for 3.10.
For 3.12 I would say that 15s are never reached.
- YGNSENDONLYONEPKT: added _isToSend() to decide if the packet is to be sent by ZWQProcess(). This to remove some packet that are send twice. Here also: really efficient for 3.10 and not harmful for 3.12
In LLCore, Sync,:
only cosmetics with LOGGING_DBG flag
In zuno_time.h :
give me access to
rtcc_micros() to be able to have a 64 bits ms timer (at last!!!
)
In ZWCCBasic:
- YGNNO_EEPROMUSE: remove zunoBasicSaveInit(...) zunoBasicSaveSet(...) and zunoBasicSaveGet(...) to avoid systematic epprom writes when receiving switch info. This is the most efficient modification for 3.12!
In ZWCCConfiguration:
- (without flag...) added const ZunoCFGParameter_t CFGPARAM_DEFAULT and const ZunoCFGParameter_t *zunoCFGParameter(size_t param) copied from 3.10's code.
This to be able to use userConfigParam from 64 to 95.
100% efficient.
In ZWCCTimer:
- YGNEXTERNVARACCESS: to copy g_Usrchannels_data into a g_channels_data to be able to read g_Usrchannels_data values form loop code. It is (was) useful to me…
In ZWSupport:
- YGNPROTECTEEPROMACCESS: added zunoGetReadyForEEpromWrite() to be called (by my loop code) before EEPROM.put to check that zuno traffic is null, if it is the case, call setEEpromBusy() to stop zwave traffic for a while (see above).
Efficiency: difficult to evaluate may be it is only a ‘straps and belt’ option ?
- YGNCHECKDIFFMESSAGE: added checkIfDifferentCmd() that is called by zuno_CommandHandler(). If two consecutive messages are identical, then it prevents re-execution of zuno_CommandHandlerbefore its main processing is done.
- YGNREDUCE_hp_time (YGNCHECKDIFFMESSAGE must be defined): receiving consecutive messages imply that g_zuno_sys->rstat_pkgs_hp_time is kept close to current time so that zunoCheckSystemQueueStatus returns always true. If two successive messages are the same, this function resets g_zuno_sys->rstat_pkgs_hp_time to the previous value.
These two modifications are:
Efficient with 3.10 (but not sufficient)
For 3.12 There are never succession of same 'usual HC3' packs. But I had to (re)implement it because of COMMAND_CLASS_CONFIGURATION exchanges, for which succession of same pack occur very often. So, for 3.12, this modification is restricted to if (ZW_CMD_CLASS == COMMAND_CLASS_CONFIGURATION).
Conclusions:
*3.12 have a far better management of zwave traffic, there are no more saturation of
'zuno_CommandHandler()'. Excepted during COMMAND_CLASS_CONFIGURATION exchanges. RQ configuration params uses,
imply EEprom operations...
* There are still some reboots with 3.12 that occurs even whith an empty
loop().
* For 3.12, most useful modifications are:
- to reduce reboots: those in ZWCCBasic, and, more generally, to reduce EEprom.puts in the loop() code
- for configuration parameters: those in ZWCCConfiguration and ZWSupport
- I think that a ‘clean’ resetBusyQueue in CommandQueue could be a good thing, in weak RF environnement there are still strange things...
- and an official millis64() would be great!
Regards,
Yves
)].
but it is really efficient for 3.10.