Script editor Topic is solved

[remb0]

It will be backwards compatible with old file based scripts

You don't have to use it at all if you don't want to. If you want to develop scripts outside Domoticz you can, then store the final version in the database if you want to.

Enable/disable will work for scripts the same way it does for Blockly currently.

Wasn't going to do an export because you can cut and paste directly in and out of the editor.

Might do syntax checker and 'run now' functionality later but want to get a first version merged

You are right! great work. Looking forward to use it.

[dannybloe]

I like the idea of editing scripts in Domoticz as well. And like some others I'd like them not to live in the database as well. I think that when this is available I will be using both ways: within Domoticz and using the filesystem. Especially for larger scripts I'd like to have a dedicated editor (WebStorm with Lua plugin) coz it also has a Lua console. But for small edits and little experiments I would be using the internal editor.

(don't forget search/replace )

And now we are at it... when this is working you can nicely integrate some Domoticz specific helper buttons/options. Like code completion where it already knows all your devices or a list of snippets with commonly used pieces of code etc etc.. sound like fun and it could really make it easier to write the scripts.

[Dnpwwo]

The editor will be fully featured from day one. It has:

• Code Completion
• Syntax checking
• Code collapsing
• 2 dozen themes
• Full key mapping schemes (editor emulation for vim, emacs, textarea & sublime)
• Visual feedback for matching brackets
• Snippets
• Search and search & replace (didn't know that until I just went into it and hit ctrl-h)

the editor is the one used in github, chrome development editor and a whole load of other places. As a developer, I found it surprisingly natural to use (checkout https://github.com/ajaxorg/ace/wiki/Def ... -Shortcuts), everything I tried worked like I thought it would.

It will also work for Python when that implementation is complete.

It doesn't know the Domoticz specific table names but i've created template code for the various event types that list them and show how to get a full list. The existing 'demo' files are pretty out of date and sparse on detail.

I don't really understand the aversion to putting scripts in the database, it makes the overall solution much cleaner and more consistent. Today if the memory card on your RPi hiccups you restore the database which brings back all data and 1/2 your scripts (the Blockly ones) straight away, then you need to fiddle around dropping files onto the file system to make the rest work (assuming you have another copy). If all scripts are in the database you just restore the last backup through the web interface and its all up and running again.

For average users (the majority) this is a no brainer.

[galadril]

Great, would love to test it..

[Westcott]

How about vim ( vi improved )?
I spent many happy years learning its commands.

[dannybloe]

I don't really understand the aversion to putting scripts in the database, it makes the overall solution much cleaner and more consistent. Today if the memory card on your RPi hiccups you restore the database which brings back all data and 1/2 your scripts (the Blockly ones) straight away, then you need to fiddle around dropping files onto the file system to make the rest work (assuming you have another copy). If all scripts are in the database you just restore the last backup through the web interface and its all up and running again.

For average users (the majority) this is a no brainer.

Well, I think this feature is not for the average user. This is for programmers/developers and they like to have their sources versioned and backed up to name one. My script folder is versioned and I edit it with non-average editors. And it is not only versioning that I want. A dedicated editor has a lot more features than you just list here and from time to time I may need them. But maybe, since scripts for domotica tend to be small (at least for me) that some sort of versioning support would help a lot to stick to a database-only version. I don't know. We'll have to see how it works . I think a lot also depends on how you manage 'files'/scripts. I don't like the way the blockly scripts are managed (not that intuitive for me, somehow I am always scared to lose something). Working with files on a file system is a lot more flexible (allows folders for instance, quick duplication/backup/experiments, multi select remove/delete/move/dupe, create importable modules for code-reuse (when you work with python a must but also with Lua)). Unless of course you tend to create a similar filesystem-like UI in Domoticz (yay!!). /me thinks about Atom based editors

Just my two cents (and I know I might not be 'average').

[remb0]

I really see some benefits:
- no right issues
- included in automated backups
- maybe faster ?
- enable/disable functionalities

But I think there are also some other challenges like:
- I include an lua file with calculation functions.

Code: Select all

 	package.path 	= package.path .. ';' .. '/home/pi/domoticz/scripts/lua/?.lua'
My 				= require('MyFunc') 

I wonder how we gonna fix that.

[dannybloe]

I wonder how we gonna fix that.

I wonder if you will be able to fix this. Maybe you can load the modules in the c-script bootstrapper additionally to the already loaded lua modules. But it would require dynamically loading all modules and unloading them as soon as you are done. I wonder if you can and want to do that with python modules. I really think you will need a proper filesystem based script system for this.
The whole point of dynamic loading of modules is that you can do that at runtime, during execution, possibly based on runtime data.

[Dnpwwo]

Day 1 there is no reason why loading additional packages from the file system wouldn't continue work as it does today because the same Lua engine is running but from a string rather than a file.

I see 4 possible options:

• if your coding has reached that level of sophistication then maybe sticking with the file system is the way to go
• You could run a hybrid of file based package and database scripts (but what's the point?)
• we create a 'domoticz.lua' package on the file system with useful common functions that would always be loaded and used across database and file system scripts.
• modules could be stored in the database and the 'require' function could be hijacked to support them in a similar way that the print function has been (sounds over the top)

[dannybloe]

I see 4 possible options:

• if your coding has reached that level of sophistication then maybe sticking with the file system is the way to go

Still think there's a 5th option: instead of doing database crud operations use a handful of os fs crud methods. Shouldn't be that hard. And enable/disable can simply be done by added _demo to the filename (or remove it). And.. you can easily extend it with folders as well, show a treeview in Domoticz for script management etc. Import/require works without hacking/hijacking. And ppl who want remote backup already have scripts that moves stuff to external systems.. A couple of event scripts could easily be added (I'm sure most of them are already part of remote backups).

[Dnpwwo]

Did you do a 'make' on the new vesion? I had to 'make clean' 1st and upgrade boost because of someone else's changes but it works fine for me both for a fresh install and upgrading an existing database with Blockly scripts in it.

Check the EventMaster table in the database, it should have new 'Interpreter' and 'Type' fields which would have been added during startup. The 'Interpreter' field should have defaulted to 'Blockly' and the 'Type' to 'All'.

Also try flushing your browser cache. I didn't need to so didn't update the appcache file but it may help.

It will only show you old Blockly events (assuming you had some) it is completely separate from file based Lua scripts.

[bizziebis]

There is definitely something wrong here. On Tweakers forum there are also reports of broken event systems. Someone commented on your commit about a missing java file. I also found it it was referring to a text.js but I cannot see in the code were it's coming from.

ernorv about 5 hours ago

commented on www/eventsframe.html in f08f52c

when using the blockly interface, somewhere along the line (did not fgure out where) js/ace/snippets/text.js is called for. The file is not there, hence a standard html page is served, breaking the JS. Added locally a file in accordance with the ACE github, and slightly changing it in accordance to what I saw in the other two files (start paste of text.js)

ace.define("ace/snippets/text",["require","exports","module"], function(require, exports, module) {
"use strict";

exports.snippetText =undefined;
exports.scope = "text";

});

Hope this helps.

Regards

[Dnpwwo]

@bizziebis, I've pushed a bug fix for users with zero scripts defined (thanks to ernorv for troubleshooting ).

I'm looking at the text.js browsers error as reported. It does not seem to impact functionality of either Blockly or Lua so you should be able to use it in the meantime.

[bizziebis]

I still can't seem to get it working:

Schermopname (23).jpg (293.54 KiB) Viewed 4689 times

I have cleared the caches but that doesn't do anything.
The text.js error is gone though.

Edit: hmm.. I think tha DB update trigger did not fire correctly according to your information

Check the EventMaster table in the database, it should have new 'Interpreter' and 'Type' fields which would have been added during startup. The 'Interpreter' field should have defaulted to 'Blockly' and the 'Type' to 'All'.

I don't have those fields. I'll try and change the DB version to see if it will trigger the DB upgrade now

Edit2: I recompiled SQLHelper and now the DB is upgraded. No function of event screen still.

[Dnpwwo]

@bizziebis, sorry to hear you are still have issues. Great post BTW, makes troubleshooting much easier when I have the details.

From your screenshot I can see that you have the correct javascript and the text.js issue has gone so you have the correct version.

I believe the issue is on the back end because the existing code just drops through and returns "OK" but no data if it doesn't understand the command (I didn't change this in case something relies on the behaviour) and I think that is the case here. I think your domoticz.exe hasn't been rebuilt properly. The fact that you

recompiled SQLHelper and now the DB is upgraded

at it fixed some things supports that.

I would recommend doing a full rebuild because SQLHelper was not the only file that changed, EventSystem did as well and I don't think you are running the new one.

Can you give that a go?

[bizziebis]

You are right. Don't know what was going on, but it seems other files were also not correctly compiled. Never had those issues before the boost upgrade. I hope it will not keep on happening in the future. It's a pain in the a** to debug this way.

But the editor is working now so I can give it a try!

Maybe nice to put a link or popup somewhere with the keyboard shortcuts: https://github.com/ajaxorg/ace/wiki/Def ... -Shortcuts

[remb0]

yes available! gonna migrate some of my scripts starting with the easy ones

Now I understand the reply of vil1driver.
In the list it's not clear what kind of script of blocky it is, so I used my original script names: script_device_thanks

Everything works! my lua scripts are in the db now.
no need for winscp anymore .
backups would be smaller and restoring easier!

[raym]

This is brilliant! A great addition. Thank you.

[schulpr]

Hi,

I did a test with a working LUA script. It seems that the same script in the script editor can't handle the "devicechanged" command. It gives an error:

2016-01-02 10:06:00.358 Error: EventSystem: [string "-- Automatische keukenverlichting..."]:26: attempt to index global 'devicechanged' (a nil value)

Any idea how to fix this?

Best regards, Rob

[Dnpwwo]

Devicechanged certainly works (it is a table not a command BTW).

This code:

Code: Select all

commandArray = {}
for deviceName,deviceValue in pairs(devicechanged) do
    if (string.find(deviceName,'PIR')) and deviceValue == "On" then
        print ("Movement Detected event fired on '"..deviceName.."', value '"..tostring(deviceValue).."'");
        if uservariables['Minutes Since Last Motion'] ~= "0" then
            commandArray['Variable:Minutes Since Last Motion'] = "0"
        end
    end
end
return commandArray

works just fine and it iterates over the whole of 'devicechanged'.

Could you post your Lua? That would help people diagnose the problem.