SmartThings Community

Home Automation Dashboard (HAD)


(Terry) #901

CWhen I put in the $ git push heroku i get the following error. Not sure what I am doing wrong.

remote: Installing stringex 1.5.1
remote: Installing uuidtools 2.1.5
remote: Your Gemfile.lock is corrupt. The following gem is missing from the DEPENDENCIES
remote: section: 'bcrypt-ruby’
remote: !
remote: ! Failed to install gems via Bundler.
remote: !
remote: ! Push rejected, failed to compile Ruby app
remote: Verifying deploy…
remote: ! Push rejected to parkhill.
! [remote rejected] master -> master (pre-receive hook declined)
error: failed to push some refs to ‘

I ugraded my Gemfile and gemfile.lock and still get the same error

I started over from scratch. I upgraded to the new gem file and gem file.lock. Created a new URL. Still getting the same error. Why is it looking for the bcrypt.ruby? Any help would be greatly appreciated

(Terry) #902

very frustrating. I followed all the instructions and still getting the corrupt.lock file. I started over from scratch several times and still get the same thing. The log shows failed to compile ruby app. Any suggestions?

C:\hadashboard>heroku logs --tail
2016-03-28T22:20:03.830688+00:00 heroku[api]: Enable Logplex by
2016-03-28T22:20:03.830688+00:00 heroku[api]: Release v2 created by
2016-03-28T22:24:11.107251+00:00 heroku[api]: Set DASHING_AUTH_TOKEN config vars by
2016-03-28T22:24:11.107282+00:00 heroku[api]: Release v3 created by
2016-03-28T22:24:28.192946+00:00 heroku[api]: Set DASHING_URI config vars by
2016-03-28T22:24:28.192946+00:00 heroku[api]: Release v4 created by
2016-03-28T22:24:42.842236+00:00 heroku[api]: Set HEROKU_OAUTH_EMAIL config vars by
2016-03-28T22:24:42.842236+00:00 heroku[api]: Release v5 created by
2016-03-28T22:24:59.201180+00:00 heroku[api]: Set HEROKU_OAUTH_ID config vars by
2016-03-28T22:24:59.201180+00:00 heroku[api]: Release v6 created by
2016-03-28T22:25:18.387406+00:00 heroku[api]: Set HEROKU_OAUTH_SECRET config vars by
2016-03-28T22:25:18.387406+00:00 heroku[api]: Release v7 created by
2016-03-28T22:25:33.745417+00:00 heroku[api]: Set SESSION_SECRET config vars by
2016-03-28T22:25:33.745417+00:00 heroku[api]: Release v8 created by
2016-03-28T22:25:46.454413+00:00 heroku[api]: Set ST_CLIENT_ID config vars by
2016-03-28T22:25:46.454413+00:00 heroku[api]: Release v9 created by
2016-03-28T22:25:59.441051+00:00 heroku[api]: Set ST_CLIENT_SECRET config vars by
2016-03-28T22:25:59.441051+00:00 heroku[api]: Release v10 created by
2016-03-28T22:26:26.007726+00:00 heroku[api]: Attach DATABASE resource by
2016-03-28T22:26:26.007726+00:00 heroku[api]: Release v11 created by
2016-03-28T22:32:50.655059+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:32:50.655068+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:34:57.507835+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:34:57.507853+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:39:00.645567+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:39:00.645573+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:40:34.347748+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:40:34.347760+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:42:09.938387+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:42:09.938393+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:42:47.958879+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:42:47.958884+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:45:27.054274+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:45:27.054268+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:46:28.379507+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:46:28.379512+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app
2016-03-28T22:53:15.568801+00:00 heroku[slug-compiler]: Slug compilation started
2016-03-28T22:53:15.568810+00:00 heroku[slug-compiler]: Slug compilation failed: failed to compile Ruby app

(Brandon) #903

@Gietlt, please read the last few posts before yours.

(Steven) #904

So, I feel like I’ve fought with this for entirely too long, and I’m about ready to throw in the danged towel!

I noticed that my dashboard was only providing me with updated status and the ability to toggle for only a single one of the bulbs in my house. This is one that I’ve had for quite some time. For the new bulbs, it wouldn’t show me their status, nor would tapping on the widget cause the bulb to change state. After tons and tons of debugging, I noticed that they all seemed to be assigned to a different version of the SmartApp than the one that was actually working. It seemed that no matter what I did, I couldn’t get them to authorize with the new version of the app (only noticeable by going to my devices in, and hovering over the Dashing application, and inspecting the UUID listed in the URL).

I fought with it for quite some time, finally said screw it, destroyed everything I did, and created a brand new Heroku application, updated to fix the corrupt gemfile, updated to Ruby 2.3 merge request, generating UUIDs for the client, copying Heroku’s “hadashboard” OAUTH client information, and copying the created SmartThings UUID information, adding it all to the Heroku config, and publishing everything. After ALL THAT, I’m now at a state where I have a dashboard, and now NONE of my devices are allowing me to tap and update their state, nor do they show the correct state when the dashboard is loaded.

I’ve fought with this for no less than 7 hours over the past two days, and am at my wits’ end. It’s probably something stupidly obvious, but I can’t seem to find it. The only thing that I’ve noticed through it all is that now, when I look at the list of datapoints that the SmartApp is able to see, they’re all blank. For example, under Application State, I see:

widgets {water={}, humidity={}, presence={}, lock={}, power={}, switch={}, dimmer={}, motion={}, contact={}, temperature={}, mode=[]}

When instead, it should show something like:

widgets {contact={FrontDoorSensor=frontdoorsensor}, mode=[mode, nightmode], temperature={Utility Closet=uctemp, FrontDoorSensor=frontdoorsensortemp}}

So, I’m at a loss. I’ve gone to /smartthings/authorize over and over, authorized the thing, checked all the devices, and it still doesn’t work.

Anyone have ANY idea why? I’m at a complete loss, and don’t even know where to look anymore for trying to figure this out. It’s driving me crazy!

( co-founder Terry @ActionTiles; GitHub: @cosmicpuppy) #905

###Loss of Application State ("state.*") is a known Platform issue.

@slagle, @jody.albritton have said that a resolution is close, but they best say it in their own words.

There’s more info buried in a few other Topics …

(Steven) #906

So, it appears that all I needed to do in the end was to complain…

After posting this, I tried once more, by deleting the existing references to the app, and then re-authorizing it once more using the /smartthings/authorize link. (I SWEAR I did that before…) Lo’ and behold, it works! Suddenly it now can access all of my devices, and properly toggle their states as well with the widgets. Go figure!

Now I’m noticing though that they’re not updating their statuses when they are changed from a separate source (ex., from the SmartThings app on my phone). I presume this is the known platform issue you mentioned? This used to work before. I take it it’s a somewhat recent issue? It is actually showing the correct widget information now under Application State. It’s just not updating their state on the page itself if changed by an external source.

(Kavvy) #907

If anyone has the 7’ fire tablet, and wants a wall mount specifically for it, head here:

(Michael) #908

My gemlock file matches your updated version, @bmmiller, but I still see the failure to push due to the missing dependency, bcrypt-ruby. Any thoughts?

(Brandon) #909

My first guess would be that you aren’t actually using the right Gemfile.lock file. The current version includes bcrypt-ruby, so you shouldn’t be getting the error.

See this:

(Michael) #910

I’m definitely using that one. Bcrypt-ruby from line 6.

I tried to run a bundle update but I can’t seem to get the git shell to use ruby 2.3.0. It seems to be pointing to a 2.2.0 version that I presume came with the horoku toolbelt so the bundle update fails. I have 2.3.0 local but I’m not a terribly experienced programmer in modern terms and a bunch of fooling around and a handful of tech articles have proved fruitless so far. I notice that the git shell seems to be using 2.2.0 (at least according to the bundler) while the build states it is using 2.2.4 even though the gemfile clearly designates 2.3.0. That help spark my likely issue?

I’m sure I’ve caused more damage than helped at this point so I may start over and see how I do.

(Michael) #911

Started from scratch and no luck. Same issue. Confused as to why the build process states that it is using ruby 2.2.4 despite designating 2.3.0 in the gemfile.

$ git push heroku
Counting objects: 767, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (359/359), done.
Writing objects: 100% (767/767), 710.20 KiB | 0 bytes/s, done.
Total 767 (delta 383), reused 767 (delta 383)
remote: Compressing source files… done.
remote: Building source:
remote: -----> Ruby app detected
remote: -----> Compiling Ruby/Rack
remote: -----> Using Ruby version: ruby-2.2.4
remote: -----> Installing dependencies using bundler 1.11.2

And the error.

remote: Installing uuidtools 2.1.5
remote: Your Gemfile.lock is corrupt. The following gem is missing from the DEPENDENCIES
remote: section: 'bcrypt-ruby’
remote: !
remote: ! Failed to install gems via Bundler.
remote: !
remote: ! Push rejected, failed to compile Ruby app

Here are the first few lines of my gemfile.lock

addressable (2.4.0)
backports (3.6.8)
bcrypt (3.1.11)
bcrypt-ruby (3.1.5)
bcrypt (>= 3.1.3)
coffee-script (2.2.0)

(Brandon) #912

Hmm, that’s definitely a weird one trying to build with ruby-2.2.4. Here’s the output of a push I just did as an example of what you should see:

[code]Counting objects: 2, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (2/2), 445 bytes | 0 bytes/s, done.
Total 2 (delta 0), reused 0 (delta 0)
remote: Compressing source files… done.
remote: Building source:
remote: -----> Using set buildpack heroku/ruby
remote: -----> Ruby app detected
remote: -----> Compiling Ruby/Rack
remote: -----> Using Ruby version: ruby-2.3.0
remote: -----> Installing dependencies using bundler 1.11.2
remote: Running: bundle install --without development:test --path vendor/bundle --binstubs vendor/bundle/bin -j4 --deployment
remote: Using backports 3.6.8
remote: Using bcrypt 3.1.11
remote: Using addressable 2.4.0
remote: Using coffee-script-source 1.10.0
remote: Using execjs 2.0.2
remote: Using daemons 1.2.3
remote: Using rack 1.5.5
remote: Using thread_safe 0.3.5
remote: Using sass 3.2.19
remote: Using tilt 1.4.1
remote: Using multi_json 1.11.2
remote: Using hike 1.2.3
remote: Using eventmachine
remote: Using thor 0.18.1
remote: Using fastercsv 1.5.5
remote: Using json 1.8.3
remote: Using json_pure 1.8.3
remote: Using stringex 1.5.1
remote: Using uuidtools 2.1.5
remote: Using multipart-post 2.0.0
remote: Using hashie 3.4.3
remote: Using jwt 1.5.1
remote: Using multi_xml 0.5.5
remote: Using oa-core 0.3.2
remote: Using ruby-openid 2.7.0
remote: Using bundler 1.11.2
remote: Using dm-core 1.2.1
remote: Using data_objects 0.10.17
remote: Using coffee-script 2.2.0
remote: Using bcrypt-ruby 3.1.5
remote: Using tzinfo 1.2.2
remote: Using rack-protection 1.5.3
remote: Using rack-test 0.6.3
remote: Using thin 1.6.4
remote: Using faraday 0.9.2
remote: Using omniauth 1.3.1
remote: Using rack-openid 1.3.1
remote: Using ruby-openid-apps-discovery 1.2.0
remote: Using dm-aggregates 1.2.0
remote: Using dm-constraints 1.2.0
remote: Using dm-migrations 1.2.0
remote: Using dm-serializer 1.2.2
remote: Using dm-timestamps 1.2.0
remote: Using dm-transactions 1.2.0
remote: Using dm-validations 1.2.0
remote: Using dm-do-adapter 1.2.0
remote: Using do_postgres 0.10.17
remote: Using dm-types 1.2.2
remote: Using rufus-scheduler 2.0.24
remote: Using sinatra 1.4.7
remote: Using sprockets 2.10.2
remote: Using oauth2 1.1.0
remote: Using oa-openid 0.3.2
remote: Using dm-postgres-adapter 1.2.0
remote: Using data_mapper 1.2.0
remote: Using sinatra-contrib 1.4.6
remote: Using omniauth-oauth2 1.4.0
remote: Using omniauth-heroku 0.2.0
remote: Using dashing 1.3.4
remote: Bundle complete! 9 Gemfile dependencies, 59 gems now installed.
remote: Gems in the groups development and test were not installed.
remote: Bundled gems are installed into ./vendor/bundle.
remote: Bundle completed (0.33s)
remote: Cleaning up the bundler cache.
remote: -----> Discovering process types
remote: Procfile declares types -> web
remote: Default types for buildpack -> console, rake
remote: -----> Compressing…
remote: Done: 28M
remote: -----> Launching…
remote: Released v72
remote: deployed to Heroku
remote: Verifying deploy… done.
9d94f3e…b66e8f1 master -> master

Success (14187 ms @ 04/28/2016 8:26:20 AM)

Your Gemfile should look like this:

[code]source '
ruby ‘2.3.0’

gem 'dashing’
gem ‘thor’


gem 'oa-openid’
gem ‘omniauth-heroku’, '~> 0.2.0.pre’
gem ‘oauth2’


gem ‘json’


gem ‘data_mapper’


group :development do
gem 'dm-sqlite-adapter’


group :production do
gem 'dm-postgres-adapter’

(Michael) #913

Yup. Gemfile specifies 2.3.0. I tried setting a custom ruby version via an environmental variable also and that didn’t work although totally not sure I’m doing that right. When I try to do a bundle update, the bundler reports that I am using Ruby 2.2.2 but my gemfile specified 2.3.0 so it doesn’t proceed. Further confused.

(Brandon) #914

When you say you started from scratch, what did you try? An entire new heroku instance?

(Michael) #915

Ah, clarifying, no, I started from app creation, but same heroku instance. I will truly start from scratch this time and see how it goes.

(Brandon) #916

Yeah, I’m almost wondering if the instance is just in a bad state. Don’t try updating any bundles until you get a good working state.

(Michael) #917

I’m doing an uninstall/reinstall of the toolbelt as well.

(Michael) #918

Is there a reason the Heroku toolbelt (on Windows) installed Ruby 2.1.7? That is throwing me off. I have 2.3.0 installed locally but wondering why a version older than the one Heroku is currently supporting is installed with the toolbelt.

(Brandon) #919

I honestly don’t have an answer to that. After my initial install of the toolbelt, 1.5 years ago now? I haven’t bothered to even think about what it installed. I know I’ve upgraded the Ruby version since then though without issue.

(Michael) #920

The batch file that installs the CLI after the toolbelt is installed references the Ruby directory with 2.1.7. I’m going to reinstall the toolbelt, change the bat file and then reinitialize and see how that goes.