or download our Developer’s events calendar here:
[Download Now][1]
Discussion Overview :
Discussed new release notes for hub firmware
Performance improvements from the IDE
Resolving bugs around deleting users and prevented Hues app from being uninstalled, and service manager changes
Priority on SmartApps submissions, now up to Jan. 15
Building our ambassador program Hackster.io projects that you built, eventually import from community site too.
Delivering what we showcased at CES, demo : next generation hardware, platform, releasing our next gen hub: local processing, smart apps firing locally
Releasing new sensors : micro-motion, micro-multi, presence tag: New housing
Video service, along with premium services : Live-streaming, recording/motion detection/ clip base / 24-7 monitoring
Incident Management
Working on resolving issues with TCP
Discussion about expanding capabilities
Modes and Security issues
Upcoming changes about Device Lab, beta program
T-Shirt contest- Forum post until Feb 9th, 2015
Discussion critical alert mechanism as device type
Model specific device types showing relevant capabilities
Groovy and Grails isn’t going away - however potential languages support
Conversation about needs of dynamic tiles
More!
[1]: https://www.google.com/calendar/ical/physicalgraph.com_i84rmh4o3ca9a8sjr3skq86v4o@group.calendar.google.com/public/basic.ics
1 Like
tgauchat
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
2
(OMG… So yours-truly is the featured keyframe from the last call!? Sure glad I cleared the clutter off of the top of my printer / scanner before the meeting! Next time perhaps I’ll aim the camera at one of the beagles…).
As part of the agenda, can a few minutes be reserved for ST to recap some of the issues left open during the last dev call? There were a few different things that were left with “thats a good idea…” or something similar - it would be nice to know if there’s any news on those things. (Examples: expanding capabilities, a mechanism for device types to inform users of critical alerts, etc.)
agenda += discussion on the planned github integration. Not as a nag to get it done (even if it’s implied), but as a discussion to understand what ST has planned.
From the developer point of view, it’d be nice to be able to commit changes made in the IDE to github. It’d ALSO be nice to have changes in the github branch instantly show up in the IDE (or perhaps in reaction to a button press.)
As well, from a non-developer point of view, will it be set up so that a user could just type in a github link to instantly have access to a new device type or smartapp? If so, if the code pointed to by the link changes, will the user’s device type or smartapp also change with it? (a simple way to do upgrades.)
Hi All! just pinning this for visibility. Remember, tomorrow is our next Developer’s call! Join us and share with us your experience. Let us know if you have a topic you’d like to talk about here for the agenda tomorrow, like the posters above.
I would like to revisit the topic of local SmartApps on Hub v2. In particular, I’m interested in the plans for Endpoint SmartApps (including local authorization) as it was one of the unanswered items from a previous call.
I also have a sneaking suspicion licensing will be a topic of interest for many community devs.
There has been a lot of back and forth on the boards about this issue. I would like to hear the thoughts of those within SmartThings on the questions that have been raised on the forums. Particularly, any rules of the road that ST would like developers to adhere to when advertising services or hardware. I would also like to hear the ST vision for community building plans and developer evangelism.
I would also like to revisit the idea of having separate video conference maybe once a month that focused on actual development strategies and best practices. Maybe each call could produce a working smart app that solved just one particular problem. I think the videos that would be produced by such calls would be more useful to new developers as they could see how different developers would use ST to solve a problem in a real world scenario.
+= z-wave device type fingerprints - how to differentiate very similar fingerprints. For example, the following are raw descriptions of two different z-wave switches:
The one with more command classes is a GE z-wave dimmer switch (part 12724) and the one with only 5 classes is a GE z-wave fan control (part 12730.) Adding insult to injury is that ST’s default “dimmer” device type only looks for 0x26. How can a device type specify that it’s ONLY for the “fan control” and not for a dimmer switch?
Comment out the fingerprint entirely in the fan control device type, requiring that it’s manually set each time it’s needed. This is burdensome, and not user friendly at all.
Query the device’s MSR (assuming it supports it) and use the MSR report to test for the specific GE Fan Control product ID… and change the device type on the fly to “dimmer switch” if it’s not. This is clunky (code-wise) and ties the device type to the single product from a single manufacturer. If GE/Jasco releases a product bump, or if Linear/Evolve/Cooper/Leviton have a fan control, the MSR checks would have to be changed.
We’re aware that the current fingerprinting system is inadequate, and we’re working on an update to add at least manufacture/model and firmware version as fields you can match on.
Unfortunately in your case that fan switch is presenting itself as a dimmer switch – fan switches are supposed to use deviceId 0x1108. So, you won’t be able to get around hard-coding the MSR, though it will be easier when you can put it in the fingerprint instead of using the check-and-retype workaround.
oh? I wonder how much fun I’d have trying to report the “bug” to GE/Jasco. Would ST, as a member of the z-wave alliance, have better channels for reporting that issue to them?
Join us and share with us your experience. Let us know if you have a topic you’d like to talk about here for the agenda tomorrow, like the posters above.
