Stubs to avoid 404's and t-stat timeouts

[sbrown4]

On Thu, 2018-12-06 at 09:52 -0800, nebulous wrote:

@nebulous commented on this pull request. In infinitude:

• $c->app->log->debug("/systems/:system_id/energy");
• $c->render(text=>'', format=>'txt'); +};

• +post '/systems/:system_id/energy_star' => sub {

• my $c = shift;
• $c->app->log->debug("/systems/:system_id/energy_star");
• $c->render(text=>'', format=>'txt'); +};

• +post '/systems/:system_id/notifications' => sub {

• my $c = shift;
• $c->app->log->debug("/systems/:system_id/notifications");
• $c->render(text=>'', format=>'txt'); +};

• wouldn't all of the above be caught by the below /systems/:system_id/(:part)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

It doesn't match that pattern. I'm not sure why. Guess I need to read some more.

[2018-12-06 14:33:42.46316] [18301] [debug] No cache for systems-3418W001316-profile. Make Carrier request [2018-12-06 14:33:42.99524] [18301] [debug] /systems/3418W001316/profile [2018-12-06 14:33:43.01743] [18301] [debug] Saving profile [2018-12-06 14:33:43.08200] [18301] [debug] POST "/systems/3418W001316/profile" (6239aef5) [2018-12-06 14:33:43.09390] [18301] [debug] Template "not_found.development.html.ep" not found [2018-12-06 14:33:43.09538] [18301] [debug] Template "not_found.html.ep" not found [2018-12-06 14:33:43.09669] [18301] [debug] Rendering template "mojo/debug.html.ep" [2018-12-06 14:33:43.22803] [18301] [debug] Rendering template "mojo/menubar.html.ep" [2018-12-06 14:33:43.32037] [18301] [debug] 404 Not Found (0.237875s, 4.204/s)

[sbrown4]

On Thu, 2018-12-06 at 09:52 -0800, nebulous wrote:

@nebulous commented on this pull request. In infinitude:

• $c->app->log->debug("/systems/:system_id/energy");
• $c->render(text=>'', format=>'txt'); +};

• +post '/systems/:system_id/energy_star' => sub {

• my $c = shift;
• $c->app->log->debug("/systems/:system_id/energy_star");
• $c->render(text=>'', format=>'txt'); +};

• +post '/systems/:system_id/notifications' => sub {

• my $c = shift;
• $c->app->log->debug("/systems/:system_id/notifications");
• $c->render(text=>'', format=>'txt'); +};

• wouldn't all of the above be caught by the below /systems/:system_id/(:part)? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

The generated regex seems to look for the actual character '('; The only example I could find that catches what I want is '/systems/:system_id/*part'

./app routes -v gives the following compiled regex:

/systems/:system_id/(:part) .... POST systemssystem_idpart ^\/systems/([^/.]+)/(([^/.]+)/?(?:.([^/]+))?$

Also, there is a GET "/systems/3418W001316/utility_events" that doesn't get matched either, so we probably want "any", not just "post".

I'll modify the last P/R.

[nebulous]

Right you are. This is what happens when one uses too many routers and frameworks. I think it may br able to change to '/systems/:system_id/:part' but '/systems/:system_id/*part' should work equally well. 👍

[sbrown4]

On Fri, 2018-12-07 at 15:27 +0000, nebulous wrote:

@nebulous commented on this pull request. In infinitude:

@@ -340,8 +340,9 @@ post '/systems/:system_id/status' => sub { $c->render(text=>$xml, format=>'xml'); };

-post '/systems/:system_id/(:part)' => sub { +any '/systems/:system_id/*part' => sub { Why the change to any? do we expect GETs here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

At least one.

GET "/systems/3418W000000/utility_events"

[sbrown4]

On Fri, 2018-12-07 at 07:26 -0800, nebulous wrote:

Right you are. This is what happens when one uses too many routers and frameworks. I think it may br able to change to '/systems/:system_id/:part' but '/systems/:system_id/*part' should work equally well. 👍 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

You're right. I haven't found any instances where there is more than one item after the system id.

The only other problem I've found is when the api makes a change to the t-stat's system data. The change is not always reflected at the Bryant site. Changes to a t-stat's status work because the t-stat periodically posts. But, the post of the systems data is only sent to the Bryant site if the pass through window happens to be open. It's not an issue for my use case as I don't plan on using the Bryant site.

This is a really nice application. Thanks for taking the time to put it together. I was initially going to go the RS485 route with an RPI3 on top of each air handler. Your approach has infinitely fewer moving parts.

Steve