More comprehensive coding?

[Bandit]

I'm finding that using Composer to program has many limitations. I can't do all the things that I want to and it's very clunky to put the programming instructions together.

Is there any way to forgo Composer for commands and write Lua scrips with a text editor? Or are the controllers limited in the commands they can execute?

[Cyknight]

Quote

Is there any way to forgo Composer for commands and write Lua scrips with a text editor

No.

[RyanE]

8 hours ago, Bandit said:

Is there any way to forgo Composer for commands and write Lua scrips with a text editor? Or are the controllers limited in the commands they can execute?

To clarify, Composer is used to create what is typically called 'Composer Programming'.  This programming is *not* Lua, and is not executed in the same way that driver code (DriverWorks) is executed.

It is interpreted by Director when an event gets fired.

Lua is only used in DriverWorks drivers, and that code can't directly be run based on arbitrary devices' events, only on events pertaining to that driver (Composer events, as well as network/serial/proxy commands, etc.).

RyanE

[martymohr]

I guess the key question is what are you trying to accomplish? When I first got involved with ComposerHE (a few months ago) the clunkiness and blatantly obvious attempts to make it difficult to use really got to me (like you – give me a scripting language). But once I figured out how to circumvent C4’s attempt to “save you from yourself”, I have not run into any non-hardware issue that cannot be programmed. I’m not saying it’s easy – just that it’s do-able.

 

 

[Cyknight]

Quote

blatantly obvious attempts to make it difficult

You're forgetting that you are the 1% of 1% - for most, doing it in scripting would prevent them from using it at all.

[SMHarman]

To clarify, Composer is used to create what is typically called 'Composer Programming'.  This programming is *not* Lua, and is not executed in the same way that driver code (DriverWorks) is executed.

It is interpreted by Director when an event gets fired.

Lua is only used in DriverWorks drivers, and that code can't directly be run based on arbitrary devices' events, only on events pertaining to that driver (Composer events, as well as network/serial/proxy commands, etc.).

RyanE

I guess the key question is what are you trying to accomplish? When I first got involved with ComposerHE (a few months ago) the clunkiness and blatantly obvious attempts to make it difficult to use really got to me (like you – give me a scripting language). But once I figured out how to circumvent C4’s attempt to “save you from yourself”, I have not run into any non-hardware issue that cannot be programmed. I’m not saying it’s easy – just that it’s do-able.

 

 

Dealers program in the same manner on pro.

[AK1]

I think just two enhancements to offer capabilities that even the most rudimentary Application Development Environment products have would go a long way to enhance useability for Pro and HE users and likely improve the quality of users' code by making it more "logical" and readable:

* Proper support for Boolean logic - this would cut down on many lines of clunky work arounds

* Comments in code - this is my personal peeve here, after all, we should be encouraging good coding practices.

I am sure others will suggest items, these are just my personal top two.

[RyanE]

Some dealers create a global comment variable, then just assign their comments to that.

RyanE

 

[martymohr]

13 hours ago, Cyknight said:

You're forgetting that you are the 1% of 1%

Thanks for the compliment, but I tend to doubt that. Maybe top 1%.

End-users who spend the time and money to take control of their own systems tend to be tech savvy, and have probably had a computer or been around a computer their entire life. (I’m too old for that to be true.) They may not program for a living, but then again how many dealer employees are full-time programmers?

It is disingenuous for C4 to purposely make it difficult to take control of one’s own system. I’m not talking massive changes – just simply leave in some of the tools they pulled out from PRO (especially the where used report). Also make ALL agents display alphabetically and allow for renaming (as they’ve done with Lighting Scenes). These are simply changes that go a long way to making any modification to the system a lot easier.

And yes, as AK1 said, please give us the capability of adding comments (critical in any programming endeavor).

[Cyknight]

Quote

End-users who spend the time and money to take control of their own systems tend to be tech savvy,

Sorry, but no - what you consider 'tech-savvy' is nowhere near to using scripting code. You also need to understand that if C4 would have open scripting code available it would have far more potential to create actual problems than on an IFTTT script in a cloud.

If I were to give your average 'automation' tidbit of programming in script form to the average person 'to have grown up around computers' they'd fail to even remotely understand what it was about.

'Growing up around computers' doesn't translate to ability to ''program' or do scripting at all. Anymore than 'growing up' around motorized cars being a normal part of daily life means everyone's a mechanic.

I completely agree that in some ways Composer programming is restrictive, and certain things could be improved for sure - at the same time, I have a fair number of 'average joes' that are able to use it right now, as is, and understand what they are doing. They wouldn't if it were script.

 

Truth be told, if it were to change to true script, I fear a LOT of dealers would have a hard time adapting, at the very least it would create some major tech support problems for the foreseeable future.

 

[martymohr]

End-users who spend the time and money to take control of their own systems tend to be tech savvy,

Sorry, but no - what you consider 'tech-savvy' is nowhere near to using scripting code. You also need to understand that if C4 would have open scripting code available it would have far more potential to create actual problems than on an IFTTT script in a cloud.

If I were to give your average 'automation' tidbit of programming in script form to the average person 'to have grown up around computers' they'd fail to even remotely understand what it was about.

'Growing up around computers' doesn't translate to ability to ''program' or do scripting at all. Anymore than 'growing up' around motorized cars being a normal part of daily life means everyone's a mechanic.

I completely agree that in some ways Composer programming is restrictive, and certain things could be improved for sure - at the same time, I have a fair number of 'average joes' that are able to use it right now, as is, and understand what they are doing. They wouldn't if it were script.

 

Truth be told, if it were to change to true script, I fear a LOT of dealers would have a hard time adapting, at the very least it would create some major tech support problems for the foreseeable future.

 

I believe you missed my point. I'm not advocating doing away with ComposerHE in favor of scripting, I'm advocating making ComposerHE more usable.

Let's look at some of the clunkiness:

If you want to change something (eg. lighting level) you need to delete first, then re-enter. That's reminiscent of pulling out the bad tab card and replacing it with a newly punched one.

With the exception of advanced lighting (I believe - I'm not in front of my computer at the moment), nothing is in alphabetical order nor can you change the name of an agent. Name me one other data-centric program on your computer that displays everything in the sequence entered. I know it's been at least 30+ years since I've used one like that.

I've said it before and I'll say it again: I haven't found anything I can't accomplish (non-hardware) with ComposerHE (yet), but does it have to be so damn difficult (and clunky) to use?

[martymohr]

I believe you missed my point. I'm not advocating doing away with ComposerHE in favor of scripting, I'm advocating making ComposerHE more usable.

Let's look at some of the clunkiness:

If you want to change something (eg. lighting level) you need to delete first, then re-enter. That's reminiscent of pulling out the bad tab card and replacing it with a newly punched one.

With the exception of advanced lighting (I believe - I'm not in front of my computer at the moment), nothing is in alphabetical order nor can you change the name of an agent. Name me one other data-centric program on your computer that displays everything in the sequence entered. I know it's been at least 30+ years since I've used one like that.

I've said it before and I'll say it again: I haven't found anything I can't accomplish with ComposerHE (yet), but does it have to be so damn difficult to use?

Sent from my iPad using Tapatalk

[Cyknight]

Quote

I believe you missed my point. I'm not advocating doing away with ComposerHE in favor of scripting

Quote

(like you – give me a scripting language)

I believe you missed mine in that I was specifically commenting on that.

Quote

I know it's been at least 30+ years since I've used one like that

Then you've used very few in the last 30+ years. Apart from that - initially ALL programs tend to do so, including Excel and Access. As well as several other 'big names' in database programs I use and train in. There's nothign 'wrong' with having that method (as an option) - indeed it is one of the more important (and underappreciated outside of certain circles) tools to be able to do exactly that - order by entry. But that's beside the point here.

I'm not arguing "all is well" - indeed renaming and reordering would be a big step already (and overdue, especially reordering).

[AK1]

And support for comments in code please as well as Boolean support. Boolean support will reduce the number of lines of code - always a good thing.

[Bandit]

@Cyknight Ok, understood.

How and where are the commands stored in the controllers? They must be translated from the drag and drop commands to text? I'm just interested in understanding how the Composer programming is understood by controllers.

[Cyknight]

The system, in the end, is an xml file.

[South Africa C4 user]

On March 27, 2016 at 5:00 AM, AK1 said:

I think just two enhancements to offer capabilities that even the most rudimentary Application Development Environment products have would go a long way to enhance useability for Pro and HE users and likely improve the quality of users' code by making it more "logical" and readable:

* Proper support for Boolean logic - this would cut down on many lines of clunky work arounds

* Comments in code - this is my personal peeve here, after all, we should be encouraging good coding practices.

I am sure others will suggest items, these are just my personal top two.

I'd put proper copy and paste functionality ahead of this (I.e. Copy highlighted lines only)

I'd also have find and replace right up there...

These 2 plus your 2 items would have saved me many many hours of work...

[South Africa C4 user]

On March 27, 2016 at 7:35 PM, Cyknight said:

The system, in the end, is an xml file.

Yeah... I tried to use this knowledge to do some find and replace outside of Composer. It appeared to work fine (visually in Composer) but I clearly got it wrong as I killed my system and ultimately had to restore to an older version of my project 

[martymohr]

I know this is beating a dead horse, but it sure would be nice to have a few usability fixes to ComposerHE:

•    Present all lists in alphabetical order, of that’s too much bother, at least give us the ability to do a search.
•    Let us change the name of all agents so that when the functionality changes, we can also change the name (as implemented in advanced lightening).
•    Let us change an item. Why do we need to delete and then re-add?
•    As someone else suggested, only copy/paste the items highlighted instead of all items.
•    Give us a simple loop – such as loop x times - which is totally safe. Because it’s not there, we need to use variables and timers instead – making it that much easier to screw-up.

I don’t think we’re asking for enhancements out of the ordinary – in fact I believe what we are asking for are enhancements that should already be a part of the software (this is 2016 – not 1976). Nothing mentioned here should be difficult to implement – since you’ll find these capabilities in just about every other piece of software (including, I'm sure, the ones in use at C4 headquarters). Treating end-users as second-class citizens (okay, so we’re not your customers) is, in my opinion, rather short-sighted and stupid.

 

[Cyknight]

1 hour ago, South Africa C4 user said:

Yeah... I tried to use this knowledge to do some find and replace outside of Composer. It appeared to work fine (visually in Composer) but I clearly got it wrong as I killed my system and ultimately had to restore to an older version of my project 

Aye - that's why I made no additional comments beyond saying that - you are most assuredly on your own when going down that road

[Cyknight]

1 hour ago, South Africa C4 user said:

Yeah... I tried to use this knowledge to do some find and replace outside of Composer. It appeared to work fine (visually in Composer) but I clearly got it wrong as I killed my system and ultimately had to restore to an older version of my project 

Here's a tip - copy the programming, paste into a basic text editor (notepad or better yet notepad++). Then select what you need, copy and paste back>

[Cyknight]

15 minutes ago, martymohr said:

(this is 2016 – not 1976)

I just 'love' short memories - ignorance is bliss

Not withstanding that tremendous hyperbole - I don't disagree with what you 'ask' for mind.

16 minutes ago, martymohr said:

Treating end-users as second-class citizens (okay, so we’re not your customers) is, in my opinion, rather short-sighted and stupid.

Yeah - completely out of place, there's nothing different at all here for dealers, or for that matter C4's own employees.

[martymohr]

7 minutes ago, Cyknight said:

... there's nothing different at all here for dealers, or for that matter C4's own employees.

That's truly sad.

[TroyGarner]

Drivers are created using Lua sometimes as mentioned previously but the Director commands are in a C4Soap format which is an XML structure being sent over a specific port. I was able to control my lights by creating a program to do this myself but to make it usable where you don't have to manually check the ID's of things is a bit more work. Opening up a scripting interface for the programming to an end-user is like opening up a can of worms. I don't know of any other control system solution that has or will do this either. If you want to write code, learn AMX programming or SIMPL#/+ for Crestron, but it still requires that you have the software and that you're a dealer. They wouldn't open that up to the client's to use.

On 2016-04-01 at 4:07 PM, martymohr said:

That's truly sad.

What do you mean?

[Svdmerwe]

Have the same frustrations especially on variable conversions (example float to string). There is a usefull "calculator" driver that allows limited capability to use some lua commands such as tonumber() and string conversions.