Encoding error from LUA?

[Giblet535]

My first post, but I want to say first that Domoticz is very nearly an excellent automation interface. Submissive bowing, offers of strong coffee and pancakes to the team, etc.

There exists a major problem however.

A simple LUA script event:

Code: Select all

commandArray = {}
  commandArray['Variable:MyVariable']=tostring('abc')
return commandArray

It executes and sets that User string Variable, MyVariable, to an apparent value, 'abc', when viewed in the User Variables list.

A Blockly test, if MyVariable == 'abc' fails; they are not equal.

If I disable the LUA script, then set MyVariable to 'abc' from the Domoticz web interface, apparently the same value, then the Blockly test works as expected.

This is obviously an encoding issue, but how can I get around it? What text encoding is Blockly expecting, and how can I force LUA (UTF-8?) to work with Domoticz (ISO-8859-1?)

The same problem occurs with integer User Variables and LUA values, using e.g., tostring(5).

Thank you all in advance, and a Merry New Year to you all!

[Giblet535]

I tried to work around this defect by setting a virtual switch to 'On', but that test doesn't work in Blockly either.

I even tried creating an always On virtual switch, then setting another switch to that switch's current state. It appears to work, looking at the Domoticz interface, but a Blockly test of equality fails.

The dzVents subsystem doesn't appear to be compatible with Blockly, Domoticz, or both. At least, not predictably, which is the same thing.

I admit to being a Domoticz newb, so if someone can explain why LUA events can't set values that Domoticz can interpret, I'd welcome the information.

I DID find a workaround: I wrote a python script to set the required values from outside Domoticz. That works, so this is a dzVents<->Domoticz issue. Encoding, extraneous characters, or a physical null at the end of the encoded string value. Debug doesn't help. It dumps the values, which look correct in the 'less' command (displays odd encodings well).

[jvdz]

How have you established it is an encoding issue? Are you aware of the fact that when an user variable is changed by an LUA event script, no other event is fired? The variable events are only fired when an variable is updated through the JSON method. (Don't ask me why as I have failed to understand the difference in approach here. Understood ones it was to avoid indefinite loops but don't see the difference from devices yet. )

Jos

[Giblet535]

Thanks for replying!

I am assuming that it's an encoding issue due to the behavior.

I'm not expecting the dzVents event to trigger my event handler. That event handler is triggered by a virtual switch (an ESP8266 running modified Tasmota firmware). The switch-triggered Blockly event tests whether MyVariable == 'abc', and it isn't equal if that variable was set from a dzVents LUA event. I go look, or dump the User Variables, and it looks like it's equal, but Blockly thinks it isn't equal to 'abc'. It's equal according to LUA, but not Blockly. If I set that variable from the web interface (GUI or API), then Blockly will now behave as if that variable is equal to 'abc' just as it appears - either way - to be.

Can you think of something other than encoding or a munged string termination that can cause behavior like that?

Like I said, I'm a newb to this, and it's a complex system with a lot of changes in its history. I have a perfectly good workaround from an external quick/dirty C program, so my focus is more on understanding if I'm misinterpreting the documentation, or do I need to maintain a collection of Errata, and lists of "Don't Use This One Part".

Again, thanks!

[dannybloe]

If you are using the current beta then dzVents will trigger the event system if you update a variable. When setting a string variable all it does is a tostring() before sending back to Domoticz. No active encoding is done other than what the Lua subsystem does. Whatever happens at that point is not a dzVents thing but Lua in combination with C++. The same applies to every other string that is sent back and forth from Lua (either with or without dzVents) to Domoticz. So I doubt this is an encoding issue at all.

Still, I don't know why people are still not using just utf-8 everywhere. Afaik, there's no need to use any other encoding than utf-8.

[Giblet535]

There are a few players involved, for sure. I think one of them isn't playing by the rules.

I tried "= 'abc'", and "= tostring('abc')", and the variable appears to contain 'abc' in both instances, but a Blockly test of that variable for equality to 'abc' fails until it is set to 'abc' from the web interface or API.

UTF-8 is an encoding that's only meaningful for GUI input methods, and GUI output devices. The computing done with GUIs is only a very tiny fraction of the total, plus, PROFS won't save in UTF-8. (that last part's a very funny CFO-stereotype joke)