Google Assistant Marine Weatherman

Once upon a time, I decided that checking  the weather on the phone while driving is not conducive to safety.  But then I learnt about Google Assistant AI thingy that is changing the world...sorry Alexa!
And here is a story of trying to build a Google Assistant skill for accessing marine weather information.

WHY

Soo...what marine whether data am I interested in? Wind, tides, fog, swell....I am a kite-surfer and my day-to-day ability to kite depends on catching the windy days. I need to know! Since I am on north California coast I depend on NOAA and NWS.

WHAT

So here are some web weather resources I want to access via a speach-based application:

Coastal Forecasts
http://tgftp.nws.noaa.gov/data/forecasts/marine/coastal/
Tide Predictions
https://tidesandcurrents.noaa.gov/tide_predictions.html
Noaa Buoys:
https://www.ndbc.noaa.gov/mini_station_page.php?station=44017

HOW

Google Assistant AI. Well...really the AI?...That depends on your definition of 'I'.  IMHO, it is not AI - it is a speech-to-text (a very good one, mind you) then a text pattern matching filter with ability to invoke external web servers when matched a pre-canned pattern.  It can't think by itself (the 'I' in AI is rather weak).

LINGO

Here is the lingo, which took me quite a time to decipher:

Google Assistant

A user facing system that can accept user input and provide, by some magic means, relevant output. Google Assistant (GA) has a plethora of 'native skill' and ability to invoke 3rd party applications (via 'talk to XYX'). There is also notion of Actions on google..I think it's just a fancy name for an Google Asistant application?

Google Assistant Application

(aka skill...aka Action?) It is what I have created. GA apps are invoked by 'talk to XYZ', in my case it is 'talk to marine weather'. I tried to be funny but GA app name must be 2 or more words so Neptune or Poseidon did not work.

DialogFlow

Is a text pattern matching system - my application (my Google Action) is a set of text patterns, aka Intentions (read: 'user intentions', 'user statements').

(I suspect there is a close relation between defined patterns and a speech recognition as each time I update the pattern it says it's 'training...', likely speech recognition is much better if the correlator knows what to expect). DF also contain a system of describing parameters (ie the variables in intentions) via Entities and also linking intention to external web-based services (aka Fulfilment).

DialogFlow Intentions

I have mentioned the intentions. These are the patterns that constitute one user desire (intention) and DF app may have many intentions. In intention, the same thing may be expressed many different ways:

tides for bodega

give me tides for bodega 

what are the tides for bodega

bodega tides

give me bodega tides

etc..

Intentions can have parameters here a 'location' would be a parameter. One can select a part of the example sentence and make it a parameter. So:

tides for 'LOCATION'

where location is a parameter. Which brings us to entities.

DialogFlow Entity

Entity is a ... type (specification) of a parameter.  You can use predefined entity (such as 'city' 'time' 'color' etc) or define your own or ... use @sys.any which is ...well anything.

DialogFlow Fulfilment

Simple intention can have canned responses. You define them right in the dialog flow. But if you need to go to get some real time data, the fulfillment is where things get more interested. Fulfillment is essentially the GA/DF reaching to some other place in the WWW and getting a reply. So fulfillment is a www server accepting a https request returning a response. The request and response are GA-specific, JSON formatted collection of parameters. You can host this service yourself or you can use google services. The google services are called Firebase. Note, the Google Firebase is more generic than focused on GA/DF but there is a good support to make things easy.

It's all pretty convoluted and overwhelming on the first date...