Is it possible to create a alexa skill which sends back custom directives created by me back to my alexa enabled devices, so that I can parse them in responses and take action.
Thanks
In your example, Alexa start service1, service1 becomes the invocation (e.g. skill) name. This is fixed as one per skill. So, you can what you've explicitly requested. Some additional info that may be helpful:
As for other content after the invocation, it isn't clear there is a mode to get the Echo to recognize anything. I've heard some suggest providing very large intent sample lists or long slot dictionaries and it convinces the system to provide a more open recognition, but I've never seen that behavior myself.
If you list of items can be constrained, you can create multiple skills. For a personal, aka developer setup, this works well. I have multiple echos on the same account. I have two defined skills that route to the same ASK service layer on my PI. The launch URL routes the request into two different paths that are parsed on my NodeJS logic setting up different defaults in my code.
This allows my wife's version of the skill to work differently than mine. We just use different invocation names without having to have separate accounts and implementing oAuth.
Sorry this is old but I just spotted it while searching something else. In case you have not solved it, the answer is yes. I use my Rpi with Alexa this way. If you are publishing a skill you need to use proper security measures that include account linking, Oauth2 etc. and there are limits on the types of commands you can accept without a user PIN. However, if you are willing to assume the risk on a skill for your own use in developer mode, you can put http calls, with or without basic authentication, directly into your skill code as though it were any other public ip address. As long as your pi is addressable from outside via http, you can command it. I use my pi with a web server to control a media center. I was sending Alexa commands to that via smart things, but now also have developed a custom skill to go straight fro Alexa tot he Pi and to link commands together. I can say "Alexa, start listening..." and then send multiple menu commands via voice that are recognized by the Pi and executed (e.g. menu, guide, page down, channel name, select, etc...) until I exit or it times out due to no input. I don't have to repeat "Alexa" or "turn on/off" as though each command were a device as is the case when going through smart things. I would only recommend this if your htpc and pi have no secure data and are firewalled from the rest of your network.
Related
The alexa skill gets launched from echo device Kitchen and shall do a dialogue using echo device Bedroom as example.
Is it possible at all?
How to do it in node.js or python?
This should be done by a skill not by a routine because the actual target device is retrieved via a REST api.
This seems like a common task. Surprisingly I was not able to even figure out, if it is possible at all. Maybe it is too common.
I don't believe it's possible to achieve the CX you described with Alexa Skill Kits today.
As an end-user, you can use the announcement feature to broadcast a message to all of your supported Alexa devices, e.g. "Alexa, announce dinner is ready". You can exclude certain devices by turning on "Do Not Disturb" mode, or disabling the announcement feature in their device setting.
If you're an enterprise customer (e.g. business, healthcare, hospitality...etc.), you can use the Alexa Smart Properties API to send an announcement to a specific device you manage.
For ASK, the closest thing is the Notification API. But the CX is a bit different, like the user needs to say "Alexa, read my notifications", and you can't target a specific echo device.
I'm curious about your use case. As a skill developer, why do you want to send a dialogue to a different echo device?
I have to control a modem Cinterion ELS61 with a host application. Can anyone tell me in simple words which is the real difference among at+creg?, at+cgreg? and at+cereg? commands?
I know that cgreg is related to 2G and 3G radio access technology and cereg with 4G/LTE one, but the actual differences are not so clear and neither the relation with the creg command results.
It follows an example from a real case:
AT+CREG?
+CREG: 2,5,"38AD","02531900",7
OK
AT+CGREG?
+CGREG: 2,4
OK
AT+CEREG?
+CEREG: 2,5,"2AF2","02531900",7
OK
What is the difference among the answers to +creg and +cereg? Aren't they quite the same? And by the way, what does it mean that the same cell (02531900) has 2 difference location area codes (i.e. 38AD and 2AF2)?
Thanks for the attention
All the +C*REG commands, as you probably know, query the status of the registration to some network.
The first step is the following categorization:
+CREG, that queries the registration to the circuit switched network.
It is basically the GSM "classic" network, on which voice/data calls and SMSs are based
+C*REG commands, that query the registration to the packet networks.
They are the networks on which the packed data traffic is based. The network allowing the access to internet, to be clear.
+C*REG commands are technology specific commands:
+CGREG queries the registration to GPRS network
+CEREG queries the registration to LTE data packet network, and in some cases is mandatory also to perform tasks that were usually based on GSM: voice calls (if VoLTE, Voice Over LTE, is supported) or to sent SMSs (IMS protocol).
LTE technology, basically, moves almost everithing on packet traffic
The reason why different commands are available (even in the same cellular module) is that different registration processes are required for each sub-network.
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
But I can't seem to find much about how the NX protocol actually works. I have heard it does something with sending X11 commands. But does this mean that the listening clients need to have an x server to run the actual commands and display them?
Basically, I am trying to figure out if it is possible to write an NX client for a web browser, because it sounds interesting to me. Thoughts?
Yes. NX is essentially compressed X-Window protocol.
It's not a spec, but here is a general introduction to how it works: http://www.nomachine.com/documents/NX-XProtocolCompression.php
The client doesn't need to be an X-server, but it will probably need to be able to handle at least some subset of the X protocol.
If you are going to create an web based NX client, make sure you look at noVNC which is a web based VNC/RFB client. Better yet, fork noVNC and add NX support. That way you don't have to waste time on input, events positioning, networking, etc.
Disclaimer: I am the creator of noVNC. Implementing other remote desktop protocols (NX, RDP, Spice) is on my long term todo list (part of the reason for the name). If you're serious, contact me via github and I can give you some direction/thoughts and put you in touch with somebody else who has also expressed interest.
Let's suppose you deploy a network-attached appliances (small form factor PCs) in the field. You want to allow these to call home after being powered on, then be identified and activated by end users.
Our current plan involves the user entering the MAC address into an activation page on our web site. Later our software (running on the box) will read the address from the interface and transmit this in a "call home" packet. If it matches, the server response with customer information and the box is activated.
We like this approach because it's easy to access, and usually printed on external labels (FCC requirement?).
Any problems to watch out for? (The hardware in use is small form factor so all NICs, etc are embedded and would be very hard to change. Customers don't normally have direct acccess to the OS in any way).
I know Microsoft does some crazy fuzzy-hashing function for Windows activation using PCI device IDs, memory size, etc. But that seems overkill for our needs.
--
#Neall Basically, calling into our server, for purposes of this discussion you could call us the manufacturer.
Neall is correct, we're just using the address as a constant. We will read it and transmit it within another packet (let's say HTTP POST), not depending on getting it somehow from Ethernet frames.
I don't think that the well-known spoofability of MAC addresses is an issue in this case. I think tweakt is just wanting to use them for initial identification. The device can read its own MAC address, and the installer can (as long as it's printed on a label) read the same number and know, "OK - this is the box that I put at location A."
tweakt - would these boxes be calling into the manufacturer's server, or the server of the company/person using them (or are those the same thing in this case)?
I don't think there's anything magic about what you're doing here - couldn't what you're doing be described as:
"At production we burn a unique number into each of our devices which is both readable by the end user (it's on the label) and accessible to the internal processor. Our users have to enter this number into our website along with their credit-card details, and the box subsequently contacts to the website for permission to operate"
"Coincidentally we also use this number as the MAC address for network packets as we have to uniquely assign that during production anyway, so it saved us duplicating this bit of work"
I would say the two obvious hazards are:
People hack around with your device and change this address to one which someone else has already activated. Whether this is likely to happen depends on some relationship between how hard it is and how expensive whatever they get to steal is. You might want to think about how easily they can take a firmware upgrade file and get the code out of it.
Someone uses a combination of firewall/router rules and a bit of custom software to generate a server which replicates the operation of your 'auth server' and grants permission to the device to proceed. You could make this harder with some combination of hashing/PKE as part of the protocol.
As ever, some tedious, expensive one-off hack is largely irrelevant, what you don't want is a class-break which can be distributed over the internet to every thieving dweep.
The MAC address is as unique as a serial number printed on a manual/sticker.
Microsoft does hashing to prevent MAC address spoofing, and to allow a bit more privacy.
With the only MAC approach, you can easily match a device to a customer by only being in the same subnet. The hash prevents that, by being opaque to what criteria are used and no way to reverse engineer individual parts.
(see password hashing)
From a security perspective, I know that it is possible to spoof a MAC, though I am not entirely sure how difficult it is or what it entails.
Otherwise, if the customers don't have easy access to the hardware or the OS, you should be fairly safe doing this... probably best to put a warning sticker on saying that messing with anything will disrupt communication to the server.