Also would love to see along with the ability to share the app through links, a way to auto update changes in the app or device.
Ahhh yes! Can’t believe i forgot this! If i make and update to one of my apps, it should update on anyones IDE/mobile device.
Ran into this myself, while there are work around they should not be necessary. love the idea of a variable tired to the hub or home that can be used across all devices and applications
Ok, in addition to what others requested, here’s my #1:
- Allow generation of access tokens via IDE.
It’s a huge pain for developers to jump through a normal OAuth hoops. Most cloud services allow self-authentication without compromising security.
AND locations! (20 chars)
A way to define which mobile devices push notifications are sent to, especially when testing.
Wife hates me for this one, she refuses to reinstall the app after I was testing push notifications with a contact sensor…
Virtual notification would be a nice feature too so we can see the result without having to actually push a message. Yes I know the app has the message log, but the IDE doesn’t have access or visibility.
Fix logging. Actually log everything that is supposed to be logged. Includes calls from child devices and reporting any errors that are preventing logging.
Everything else would be nice to, but logging is my big one.
My vote goes to these two:
- git (GitHub) integration. I’d like to edit my apps in my own editor (vim) and push to a repo where it would be picked up and refreshed if already previously published.
- search, sort, filter shared SmartApps. And copy/install without having to create a dummy SmartApp of my own.
One more thing:
- allow sharing custom device types similar to shared apps.
This. Yes. As much as I love being able to code my own SmartApps, the whole model of having to code custom Groovy code to change the state of devices in response to events is fundamentally broken.
This is also so basic and important. Right now we have exactly ONE global state variable, and that’s not really sufficient to manage a whole house. There’s a lot more than “Home” / “Away” / “Night” and the like. Being able to add new states is fine, but we need to have separate states for each subsystem. Particularly as people start to try implementing scene controllers, they’re going to need to implement states per room or per system.
A few other things:
- Consumer-facing visual status display of all Things in my Locations (I’m going to have to screw around with a whole Oauth pile in order to query this programmatically for a home status display device, but via a web browser this should be basic service).
- Flexible rulebuilder system to allow me to sequence actions in response to trigger events. There’s no reason a consumer should have to write a custom application if the particular combination of actions they want to perform in sequence hasn’t been added to a list of apps. I can’t state the importance of this strongly enough.
- As an addition to (1) above, it would be good to get a global battery status view of your Things, so you can tell which you’re going to need to replace. With several dozen Things in place, most of which are battery-powered, keeping the batteries charged is a regular maintenance task.
I’d like to be able to sort by column in the Web-Based IDE. For example, under My Devices I’d like to be able to sort by Group simply by clicking on the Group column header.
I would also like to be able to choose images for my devices from the My Devices window. Also, be able to make new device groups.
Also related to my logging requests: line numbers for everything. The line the log statement is, the line an error occurred, any other messages with lines.
Nice to have would be the ability to use a local editor and have an fast and easy way to update a published SmartApp. This could just be an api call and we can hack together the file listener side.
Agree. The built-in editor is a joke - there’s not even find/replace function.
The built-in editor can simulate device and show you real ones. Let’s see your IDE do that.
Haha. Couldn’t resist.
So when I’m saying that your shoes are crap, your answer is yes, but my tie is awesome.
+1 for a find and replace for sure…
logging to a file, I’ve been tempted to write a web based server logging tool, which would log my debug requests so I have persistent logs…
Ideally, log.toFile would write all log messages including the long ones, and then there would be a link on the side of the IDE to click to download the log.txt file for the simulator.
Yes but you start to go into areas where security becomes more of a problem with logging to a local file. I like the idea, but not locally due to the fact that would be opening up their security (if you happen to have bad security in your network) this could be a way for some zealous hacker to make his way into ST.
Security isn’t really an issue with a persistent text file… It’s just raw read access only, wouldn’t have any database storage like the current log.debug function does… In fact, one could argue the current logging infrastructure is far more vulnerable…
This would simply write out a text file server side, just like cameras write images to the cloud, and then only in the IDE would you be able to view the text file.
@pstuart you might be right there. I know from where I work, that we deal with issues similar to this all the time. But, this is not my area of expertise. So I will defer to you (SMILE)