When I give command "Open the device 30 percent", the data received by intent fulfillment is
{
"command": "action.devices.commands.OpenClose",
"params": {
"followUpToken": "00f38e7b45edbc12fafce49c23568896b7feea58a8a4ba873f31abad7db96de28a25389a2987c7f8deff41afcb25fdffb2b81fe2",
"openPercent": 100
}
}
As shown above, the "openPercent" is not correctly interpreted. But if I give command "Close the device 70 percent", the data received by intent fulfillment is
{
"command": "action.devices.commands.OpenClose",
"params": {
"followUpToken": "00f38e7b4588ad650859efe30a46d7dcb565e3a7eea257919678d5cda32fd769f290298ec8c9d40d0eb3a1b52b0063921823a39d",
"openPercent": 30
}
}
So we can see that the "openPercent" is correctly interpreted for this command.
Just wondering what caused the action.devices.commands.OpenClose trait only works partially.
There are two main possibilities of what might be going wrong with the device trait on this one: Your execution might not be interpreted correctly by the Google systems, or your device definition might be in a way such that Google sends you a discrete fully open intent.
To check if the issue is with the interpretation, you can try typing out the command as well as speaking it via voice, to see if Google sends you different values with the execution intent. Please also try our different grammar, such as “Open the device 30 percent”, “Open the device”, “Set the device to 50 open”, “Partially open the device 60 percent” to see if any of these would help. It might be possible that your intent to open might be always recognized as “100%”.
The second possibility is that your device definition might lead Google to send you discrete states of fully open & fully close (or one of these, as in your case). To troubleshoot, please check your Sync response for any potential issues on how you define the trait attributes.
Related
I'm struggling to complete the development for a SmartHome action on our security panels, involving different trait implementations (including ArmDisarm, Power, Thermostats, etc.).
One specific problem is related to Toggles Trait.
I need to accept commands to enable or disable intrusion sensor bypass/exclusion.
I've added to the SYNC response the following block, for instance, for a window sensor in the kitchen:
{
'id': '...some device id...',
'name': {'name': 'Window Sensor'},
'roomHint': 'Kitchen',
'type': 'action.devices.types.SENSOR',
'traits': 'action.devices.traits.Toggles',
'willReportState': true,
'attributes': {
'commandOnlyToggles': false,
'queryOnlyToggles': false,
'availableToggles': [
{
'name': 'bypass',
'name_values': {
{ 'name_synonym': ['bypass', 'bypassed', 'exclusion'}, 'lang': 'en'],
{ 'name_synonym': ['escluso', 'bypass', 'esclusa', 'esclusione'], 'lang': 'it'}
},
}
]
}
}
I was able to trigger the EXECUTE intent by saying
"Turn on bypass on Window Sensor" (although very unnatural).
I was able to trigger the QUERY intent by saying
"Is bypass on Window Sensor?" (even more unnatural).
These two utterances where found somewhere in a remote corner of a blog.
My problem is with Italian language (and also other western EU languages such as French/Spanish/German).
The EXECUTE Intent seems to be triggered by this utterance (I bet no Italian guy will ever say anything like that):
"Attiva escluso su Sensore Finestra"
(in this example the name provided in the SYNC request was translated from "Window Sensor" to "Sensore Finestra" when running in the context of an Italian linked account).
However I was not able to find the utterance for the QUERY request, I've tried everything that could make some sense, but the QUERY intent never gets triggered, and the assistant redirects me to a simple search on the web.
Why is there such a mistery over utterances? The sample English utterances in assistant docs are very limited, and most of the times it's difficult to guess their counterpart in specific languages; furthermore no one from AOG has ever been able to give me any piece of information on this topic.
It's been more than a year now for me, trying to create a reference guide for utterances to be included in our device user manual, but still with no luck.
Can any one of you point me to some reference?
Or is there anything wrong with my SYNC data?
You can file a bug on the public tracker and include the QUERYs you have attempted. Since the execution intents seem to work, it may just be a bug in the backend grammar that isn't triggering.
I am new to Ardupilot.
Recently, I am trying to run the example "guided_set_speed_yaw" in dronekit-python api. here
Oddly, the "send_nav_velocity" in line 47 does not work (no "Got MAVLink msg" response and nothing happened during real flight tests), while "condition_yaw" in line 67 works.
I am running the script in Odroid U3 with an IRIS quadcopter. The firmware version is V3.3-dev. I basically followed this website to come to this far.
Maybe it's because of the firmware version? Thanks for any help!
The URL to the example is https://github.com/diydrones/dronekit-python/blob/master/examples/guided_set_speed_yaw/guided_set_speed_yaw.py (note "examples" not "example"). This is much more "full" version of the example code.
The reason you're not getting a response is that I don't think one is sent - ArduPilot sends a response for COMMAND_LONG messages (as used to send CONDITION_YAW), but not necessarily other message types (as used to send the velocity).
When sending emails via javamail, the following is always appended to the bottom of each message:
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager. This message contains confidential information and
is intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by e-mail if you have received
this e-mail by mistake and delete this e-mail from your system. If you
are not the intended recipient you are notified that disclosing,
copying, distributing or taking any action in reliance on the contents
of this information is strictly prohibited.
How does one prevent this?
(NOTE: This problem is extremely frustrating to research on the web due to the fact that a disclaimer of this form is attached to so many indexed documents! :-(
JavaMail is not doing that, it is your outgoing SMTP server appending it to each message, probably set up by IT.
To confirm, you can use gmail's servers (with a personal account) and you will see it does not get added to the messages.
This should work. Pay attention to the form in which email body get parsed. In my case the emailBody string is on one line, so you have to put the "#Your disclaimer Here#" on one line. Answer for who will come in future.
public String deleteDisclaimer(String emailBody) {
String disclaimer = "#Your disclaimer here#";
if (emailBody.contains(disclaimer)) {
System.out.println("Deleting Disclaimer..");
return emailBody.substring(0,emailBody.indexOf(disclaimer));
}
System.out.println("DISCLAIMER NOT FOUND!");
return emailBody;
}
I have some Windows PCs sending snmpt traps to a linux server. On the server a snmptt trap handler, that works fine except for one issue.
Windows sends out traps with a description (say "Adobe Flash player update service stopped"). My problem is I don't know how to receive this description. Using snmptt (link to doc page), I only get the trapoid,community, category, uptime, hostname, etc, but no description.
Problem is that the Windows trapOID only states that "a service has been stopped". You understand that this is not a very useful info.
With tcpdump I can see the trap coming:
> { SNMPv1 C=dst0pc10 { Trap(298)
> E:311.1.13.1.23.83.101.114.118.105.99.101.32.67.111.110.116.114.111.108.32.77.97.110.97.103.101.114 78.168.1.161 enterpriseSpecific s=1073748860 1213932 E:311.1.13.1.9999.1.0=49_6c_20_73_65_72_76_69_7a_69_6f_20_48_50_20_50_6f_72_74_20_52_65_73_6f_6c_76_65_72_20_e8_20_6f_72_61_20_69_6e_20_6d_6f_64_61_6c_69_74_e0_20_61_72_72_65_73_74_61_74_6f_2e_0d_0a
> E:311.1.13.1.9999.2.0="Unknown" E:311.1.13.1.9999.3.0="PCMAGA"
> E:311.1.13.1.9999.4.0="4" E:311.1.13.1.9999.5.0="0"
> E:311.1.13.1.9999.6.0="HP Port Resolver"
> E:311.1.13.1.9999.7.0="stopped" } }
I have big difficulties in understanding how to receive and log those descriptions. Any clue?
Ok, posting a question here usually boost my luck. I've found this simple answer:
In snmptt.conf file, the FORMAT directive could be set as
FORMAT $*
to put all the description in the "formatline" field of the database generated by snmptt.
Another problem arise, hope I can work it out soon: some descrption are in HEX format. Got to find a way to convert them.
I'm using Twilio to send sms's with appengine. Twilio doesn't accept sms's longer than 160 characters so I have to split them. I am splitting the sms's and sending them as follows:
def send_sms_via_twilio(mobile_number, message_text):
client = TwilioRestClient(twilio_account_sid , twilio_auth_token)
message = client.sms.messages.create(to=mobile_number, from_=my_twilio_number, body=message_text)
split_list = split_sms(long_message)
for each_message in split_list:
send_sms_via_twilio(each_message)
However I found that the order of sending varied. For example sometimes I'd recieve message 2/5 then 1/5 then 4/5 etc and other times the order would be correct. The order of the split_list is definately correct. To overcome the incorrect order of the sms's I tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1)
However I encountered the same problem. I then tried
for each_message in split_list:
deferred.defer(send_sms_via_twilio, each_message, _countdown=1, _queue="send-text-message")
and defined my queue as
- name: send-text-message
rate: 1/s
bucket_size: 10
max_concurrent_requests: 1
retry_parameters:
task_retry_limit: 5
Thinking that the issue was concurrency (running in python27) and that if I limited max_concurrent_requests this issue would be solved. However the issue is still present i.e. the texts still get sent in the wrong order. I checked the logs but couldnt see any notification of task failure - they just seem to be executing in the wrong order.
Is there something I am missing? How can I fix this issue.
Note that the SMS messaging (specifically the underlying protocols like SMPP) are asynchronous by definition. It means there is no way you can specify the order of distinct SMS messages.
There is a way to specify the order of SMS packets by using the UDH (user defined headers) in the binary body of those messages. But this works only for long SMS messages -- those that are too long to be sent in one message. For example, if your msg exceeds 160 GSM-7 characters or 80 UTF-16 characters it will be send as more than one message with UDH.
In that case the mobile phone won't show message parts as they arrive. It will collect them in memory until the last one comes and then assembles them in the right order. For the end user this is just a message longer than usual and you don't have to write "1/3", "2/3", ... in the message.
Disclaimer: I work for a company that enables you to send and receive both multiple binary messages with user-specified headers (UDH) and/or standard long messages.
If you are not tied to Twilio try using SMSified. They automatically split the message for you, insure it is in the correct order, and add "1/2, 2/2..." to the end of the message. In other words you just send the complete message to their REST API, no matter the length, and they handle the rest. Since they also use a REST API you can continue to use Python.