Example StateChart
I've got a system, that is depending on another system.
I want to display this in a statechart.
System 1: microwave_state with two states: On and Off
When microwave_button is pressed AND system 2 current state is true, then ON
else Off
System 2: electricity_state with two states: True and False.
When electricity bill is payed then True else False
How can I display that dependency in a statachart?
You would do it like this:
The "current from system2" is just a guard for the transition. From my POV system2 is not a state machine, but a simple boolean value.
Related
Using feature toggles in Azure Feature Manager gives the option to configure a label when creating a feature, in .NET to use that label the only option I could find is to set the label during startup when configuring Azure App Configuration which can be done like:
config.AddAzureAppConfiguration(
options =>
{
options.Connect(settings.GetConnectionString("Config"))
.UseFeatureFlags(o =>
{
o.Label = "Test";
o.CacheExpirationInterval = TimeSpan.FromSeconds(1);
});
},
The problem with that approach is during runtime we can't change the label, as it is pre-configured during startup.
The question is how can we manage different labels, let's say I have 100 labels and I want my application to evaluate feature toggle with respect to its label there is no way I could find to achieve that.
To evaluate feature toggle we call feature manager like so
await _featureManager.IsEnabledAsync(setting);
I'd say you can't, and this is not a bad thing. Labels are there so that you can have one feature flag saved two times, possible with different values and filters. E.g.:
MyFlag (Label: test) true
MyFlag (Label: production) false
or
MyFlag (Label: america) true
MyFlag (Label: asia) false
So you should use labels to save different values for one feature for different stages or for different regions or whatever other use cases you may have. You are not supposed to switch between labels in a running application.
Is there a way to specify that a session should be ended, or to clear out the memory of previous actions? In my testing (simulator only) I'm seeing a couple cases where Bixby is remembering a previous entry that isn't relevant anymore.
Example utterances
remove wet diaper
wet diaper
In this case there's 2 possible enums that can be said. "actionType" that is optional, in this case "remove" and "statType", in this case "wet diaper".
What is happening is on the second phrase it's caching the actionType. So, the second phrase my JavaScript still receives the "remove" even though it's not included.
I haven't tried this on an actual device (only the simulator) so it's possible this is just a simulation quirk.
This is kind of related to this question. There was a follow-up comment that the OP asked related to session management.
How does Bixby retain data from a previous NL input?
So, if you read that link. Is there a way I can signal to bixby that the conversation is over, or at least to not remember previous entries for the action?
One way would be to use the transient feature. Here is more information
For example, alter your input type so it doesn't carry over across executions.
name (ActionType) {
features {
transient
}
}
make sure all input types are NL friendly. name/enum concepts are meant for NL and you can attach vocabulary to them.
I used to have a similar issue like yours, in my case, my problem was related to the type of the 'requires' property inside the input-group declared in my action.model.bxb.
You need to handle by separate this two input cases in diferent action.model.bxb files:
In one of them you might have something like (model 1):
input-group(removeWeaper){
requires (OneOrMoreOf)
collect{
input (ActionType) {
type (Type)
min (Optional)
}
input (StatType) {
type (Type)
min (Optional)
}
}
Here, Bixby Will know that at least one of these properties will be apear in your input and will be waiting for an input with that structure.
In the other file you might have (model 2):
input-group(Weaper){
requires (OneOf)
collect{
input (StatType) {
type (Type)
min (Optional)
}
}
Here, Bixby will be waiting to catch an input that contains only one of the indicated values in you input.
(model 1) This could be ok only if you run 'wet diaper' by first time, also when you try again and run 'remove wet diaper' it might work, the problem is when you run again 'wet diaper' because Bixby Stores you previous approach including "remove". i'm not sure if there is something to clear the stored values, but, here is when (model 2) will help you to catch only the input 'wet diaper' as a different statement.
I share you this work around as my own experience, and i hope this could help you solving or getting another perspective of how you could handle or solve your problem.
This question is similar to this one I previously asked, in that I want the task to perform a Target Worker Expression check on a list of WorkerSids that I've added as one of the task's attributes. But I think this problem is different enough to warrant its own question.
My goal is to associate a "do not contact" list of WorkerSids with a Task; these are workers who should not be assigned the task (maybe the customer previously had a bad interaction with them).
I have the following workflow configuration:
{
"task_routing":{
"filters":[
{
"filter_friendly_name":"don't call self",
"expression":"1==1",
"targets":[
{
"queue":queueSid,
"expression":"(task.caller!=worker.contact_uri) and (worker.sid not in task.do_not_contact)",
"skip_if": "workers.available == 0"
},
{
"queue":automaticQueueSid
}
]
}
],
"default_filter":{
"queue":queueSid
}
}
}
When I create a task, checking the Twilio Console, I can see that the task has the following attributes:
{"from_country":"US","do_not_contact":["WORKER_SID1_HERE","WORKER_SID_2_HERE"],
... bunch of other attributes...
}
So I know that the task has successfully been assigned the array of WorkerSids as one of its attributes.
There is only one worker who is Idle and whose attributes match the queueSid TaskQueue. That worker's SID is WORKER_SID1_HERE, so the only available worker is ineligible to receive the task reservation. So what should happen is that the first target expression worker.sid not in task.do_not_contact returns false, and the task falls through to the automaticQueueSid TaskQueue.
Instead, the task remains in queueSid unassigned. The following sequence of Taskrouter events are logged:
task-queue.entered
Task TASK_SID entered TaskQueue QUEUESID_QUEUENAME
task.created
Task TASK_SID created
workflow.target-matched
Task TASK_SID matched a workflow target
workflow.entered
Task TASK_SID entered Workflow WORKFLOW_NAME
What do I need to change to get the desired workflow behavior?
Changing the skip_if to
"skip_if": "1==1"
solved the problem.
Per Twilio developer support, the worker.sid not in task.do_not_contact returns true for workers who are unavailable but are also not in do_not_contact, so the target expression still returns a set of workers, and then the "skip_if": "workers.available==0" returns false because technically there is one "available" worker--the one who is ineligible due to the do_not_contact list.
What's needed is for the skip_if to always return true, so when the first target processes the task without assigning it, the skip_if then passes it to the next target, as discussed in Taskrouter Workflow documentation:
"TaskRouter will only skip a routing step in a Workflow if:
No Reservations are immediately created when a Task enters the routing step
The Skip Timeout expression evaluates to true"
I need to somehow record, when the light is unplugged. The bridge seems to return the 'last recorded' value. If the light was 'on' before unplugging, it still returns 'on', even after it is unplugged.
Absolutely nothing seems to be changing in the output, if the light is unplugged. Any ideas?
Yes, you can check the light's state variable named "reachable". This is set to false when the bridge fails to connect to the light, such as when it is unplugged or when a physical switch cuts the power to the light. As you noted, the other attributes just tell you what the various values were the LAST time the bridge was able to reach the light.
{
"state": {
"on": true,
...
"reachable": false
},
...
}
Additionally, you can use a rule or sensor to monitor the value of that attribute and take some action when it switches from true to false or vice versa.
The Nest Thermostat device will display on-screen if it's 'cooling' or 'heating'. How do I get this state through the Nest API?
The hvac_mode property seems to simply show what the user's Thermostat is capable of controlling and doesn't change when either cooling or heating occurs.
For now, I'm using a simple but not flawless logic:
if (can_cool && target_temperature < ambient_temperature) --> isCooling
if (can_heat && target_temperature > ambient_temperature) --> isHeating
else --> isDoingNothing
By not flawless, I mean that I've encountered situations where this logic is incorrect. For example, in a given situation where the ambient_temperature is 20 Celsius and the target_temperature is 21 Celsius with can_heat set to true, my UI will say the Thermostat is heating, while it actually isn't.
This is probably because target and ambient temperatures are too close, but I don't know what the threshold is.
Is there another or better way to figure out heating and cooling states?
As of May 2015, the Nest API now officially reports the hvac_state property. The value will be one of either 'heating','cooling' or 'off'.
New fields in the data model:
hvac_state.
You'll use hvac_state to learn if the home HVAC system is actively heating, cooling or is off.
Looking at the API, they don't provide any way of identifying if the thermostat is actually heating. The closest you can get to identify is what you currently have written.
If the device itself is capable of displaying it's heating or cooling, they must have different code or different methods (such as internal electronics) for identifying that.
Sadly you're correct - the API does not reveal this information.
In my application I've implemented the same logic as you, and have noticed the same issue around edge cases. I suspect that there may be a time-element to it when the ambient temperature is just outside of the target temperature by only a degree or less.
You need to track the status of Heat On/off in order to calculate properly. I monitor the NEST at 1 hz and store the last state (On or Off) as a variable. once you have this info you can use the following logic and it will be accurate:
if lastStatus.Contains("Off"))
{
if (temp_current < temp_setpoint)
status = "Heat On";
else
status = "Heat Off";
}
else if (lastStatus.Contains("On"))
{
if (temp_current > temp_setpoint)
status = "Heat Off";
else
status = "Heat On";
}
// Do the work....
lastStatus=status;
Note: temp_current and temp_setpoint are returned from the REST http post.
Good Luck!