Well Spotted! - Only the 1 typo? not bad for me.. im on it, but since Objlist1 is simply a short-form for ‘my test object list #1’ im inclined to adopt your label - I had put the lack of gui updates down to the change to lowercase property labels, and their use in message direction. - So its also looking for the wrong source too hmmm
Ive just scanned over your merge suggestions - would that be the code equivalent of the join node merge option? - if doable in a simple enough low node count flow i would prefer to go-node.
I'm sure that it can all be done without a function node and that is good for the clarity of the flow and maybe for speed of throughput too.
I briefly looked at doing it like this but switched back to a function when faced with extracting and updating just one of the components of a combined context variable.
Mind you, as @Colin points out, you can perhaps get away without context - accept a message and handle it's implications: Humidity value x is too low? Turn on the irrigation, etc
My V1 sys using the xiaomi-ble-contrib node was limited to the number of sensors it could query ‘easily’ within a reasonable repeatable window, a single sensor query could take minutes to successfully terminate. (local noise evident by the current ble-mqtt traffic indicates.. ??), so granularity of tests/checks triggered by message arrival was not an issue.
my solution to the sensor limitation was apply to heating in the winter and the patio plant watering in the summer.. it worked
OMG and its frequent broadcasts provides the capacity to include any number of sensors, or at least more than v1.
However the frequency of message arrival seems extreme to employ to trigger decisions on anything?
Im content to stick with the context storage option for now, if it presents problems or roadblocks in the future i guess i will be back
