Delay for otherdevices_idx update?

[lost]

Hello,

I just added a virtual text device and intended to update it 'by name' as I now do from Lua and I have other (older) working exact same exemple but here, for a new such device:

Code: Select all

--commandArray[#commandArray+1]={['UpdateDevice'] = otherdevices_idx[devMetar]..'|0|'..metarText} 
commandArray[#commandArray+1]={['UpdateDevice'] = '790|0|'..metarText}

First (commented) version does not work with this error:
attempt to concatenate a nil value (field '?')

Second, with idx explicitly set works! No error on devMetar name, of course, and this name is not already existing in my system. Cannot even print otherdevices_idx[devMetar] content for debug (same error).

As I lately converted all my Lua scripts IDX use to names using otherdevices_idx table, far after devices creation, I wonder if this table may not be updated often???

[FlyingDomotic]

otherDevices_idx is updated as soon as a new device is added, or its name modified.

If returned value is nil, it's probable an error in given name (spaces, case...). It could be a good idea to print devMetar (and devTaf before trying to extract it's idx.

Here's the function I use to set value in a text device:

Code: Select all

function setText(device, strValue) -- Set a text value
    local cmd = string.format("%d|0|%s", otherdevices_idx[device], strValue)
    table.insert (commandArray, { ['UpdateDevice'] = cmd } )
end

[lost]

It could be a good idea to print devMetar (and devTaf before trying to extract it's idx.

I now better understand your nickname
Weather is not so good for now here:

Code: Select all

LFPN 050700Z AUTO 31007KT 3700 +RA BR BKN005/// OVC062/// ///CB 15/15 Q1009 TEMPO 1500 RA
LFPN 050730Z AUTO 31011KT 5000 RA BR BKN007/// OVC060/// //////CB 15/15 Q1009 TEMPO NSW BKN005

Did what you suggested and this morning prints were correct/without errors for both device name & it's idx from table. Looking at your version, I first believed a string conversion may be missing even if this should IMO be done automagically in Lua (and I already had exact same exemples from other working scripts)... but just reverted my commented lines hereupper as a 1st try & all was OK!

So I still believe there is some (huge) amount of time for device name setting to make it's way in this otherdevices_idx table. Strange but can't see any other explanation for now.

[jvdz]

So I still believe there is some (huge) amount of time for device name setting to make it's way in this otherdevices_idx table. Strange but can't see any other explanation for now.

Just looked at the source of EventSystem.cpp and it looks like the otherdevices_idx is filled from the same input array as all other tables like otherdevices, which would imply that they are either in both or none of them.
So did the following quick test in a "play" domoticz environment with v2024.7:
1. Added text device named testtext
2. created this TIME script

Code: Select all

commandArray = {}
devMetar = 'testtext'
metarText = 'test text:' .. os.date("%X")
commandArray[#commandArray+1]={['UpdateDevice'] = otherdevices_idx[devMetar]..'|0|'..metarText} 
return commandArray

3. Waited a minute and the device was nicely updated without error.

Over to you

[jvdz]

So I still believe there is some (huge) amount of time for device name setting to make it's way in this otherdevices_idx table. Strange but can't see any other explanation for now.

Just looked at the source of EventSystem.cpp and it looks like the otherdevices_idx is filled from the same input array as all other tables like otherdevices, which would imply that they are either in both or none of them, like mentioned by @FlyingDomotic.
So did the following quick test in a "play" domoticz environment with v2024.7:
1. Added text device named testtext
2. created this TIME script

Code: Select all

commandArray = {}
devMetar = 'testtext'
metarText = 'test text:' .. os.date("%X")
commandArray[#commandArray+1]={['UpdateDevice'] = otherdevices_idx[devMetar]..'|0|'..metarText} 
return commandArray

3. Waited a minute and the device was nicely updated without error.

Over to you

[FlyingDomotic]

So I still believe there is some (huge) amount of time for device name setting to make it's way in this otherdevices_idx table. Strange but can't see any other explanation for now.

Normally, tables are loaded just before calling scripts, so everything should be ok (else it's an unsupported and undocumented feature, well known as "bug" )

However, a subtile thing to know is that scripts do store devices and user variables commands changes, and execute them as soon as you're leaving the script.

Things that won't work is to modify a device, and read it back just after. As change is postponed at end of execution, read value will be those just before script activation. Headache guaranteed!

To fix this kind of issue, read device value in local variable, update variable (and write change to device), and use modified variable instead of reading device or user variable back from tables.

[lost]

Thanks to both,

@jvdz: Did same try with same results... In my trials yesterday, I just remember to have changed the name ('METAR'->'Metar') of the virtual text device attached to dummy hardware (always named 'Metar', which was initially same as attached text device & maybe not a good idea as accessing devices by name probably require they are unique to avoid some unwanted behavior) as this was not working & I was not sure which idx was required for the update.

@FlyingDomotic: Yes, I'm aware scripts drive actions from CommandArray returned to Domoticz even system, so after script end, did not tried to read just modified value even for debug, only the idx matching name. In fact, that's otherdevices_idx[devMetar] access attempt that triggered hereupper error: For updating text device or just in a debug print, same behavior.

[zicht]

i dunno if this is the case, but maybe it helps ...

1.
In my expirence the values are saved (and usable for a script) upon the execution of <return commandArray>

I had in the past some scripts i wanted to update and react with very little time.
My solution was to use two(2) scripts and have the scriptnames starting with a number, for making it fire in the right sequence.
The first script stored the value, the second used it.
This way the stored value is availabe within 0-0.2 secs in my system.
There are some side effect, but they are manageable.

2.
I see you use otherdevices in your commandarray. That did not work for me.
Try store the value of the otherdevice_idx in a script variable and use that in the command array. Like :

Code: Select all

commandArray[#commandArray+1]={['UpdateDevice'] = otherdevices_idx[devMetar]..'|0|'..metarText}

Code: Select all

xx=otherdevices_idx[devMetar]
commandArray[#commandArray+1]={['UpdateDevice'] = xx..'|0|'..metarText}