I've been looking for a way to implement a simple sensor that only has an on or off state.
As the simple SensorState does not supporta simple on/off state I tried using a Switch with an OnOff trait, and set the queryOnlyOnOff attribute to true
The description of the attribute is Indicates if the device can only be queried for state information, and cannot be controlled through commands. As of the app still showing on/off buttons, is commands only for voice commands? If so Google needs to add a simple sensor we already have the trait for it we just need to add a simple detected/notdetected sensor to the SensorState if there is not already. Any ideas how to work around this?
Edit 1:
My current SYNC response https://gist.githubusercontent.com/DRSchlaubi/7099dc289858ae6dba72e54311fa728f/raw/4f3f9506cfe27701be00db438477c3bed8a6b0ec/sync.json
EDIT 2:
I see google specifically lists an example for sensors here
but the example is very vague and looks like you have to add it to the top-level payload which does not work as well as adding it to the attributes object
EDIT 3: I tried switching from the Switch device to a Sensor device but now it does no longer display the state in the app probably Sensor does not support StateOnOff?
Edit 4: on the sensor page it says These traits are recommended, if applicable to your device. However, you are free to mix and match from all available traits to best match your existing product functionality. however the OnOff state does not seem to display anything
Can we have a sample of variables available for redefinition of templates, documentation is scarce on this?
In Class package de.codecentric.boot.admin.notify.MailNotifier I read
private static final String DEFAULT_SUBJECT = "#{application.name} (#{application.id}) is #{to.status}";
private static final String DEFAULT_TEXT = "#{application.name} (#{application.id})\nstatus changed from #{from.status} to #{to.status}\n\n#{application.healthUrl}";
In my specific use case I inherited a bunch of applications which I want to ping or monitor they are alive. I have no control on them but my app depends on them.
My app doesn't fail but may misbehave (important point!).
So I added a bunch of customs HealthIndicator to get them monitored by ping, that work perfectly, and I was very pleased by changing an IP a notification was sent, great!
But there is a but, the message sent let me think than the app was failing, while instead the health indicator was status OUT_OF_SERVICE, unnecessary stress for DevOps.
Come to my question, how can I add some extra variables whereby some carefully crafted SPEL will distinguish an Health indicator message status change than an application status change ie webapp going offline.
Is a dictionary of SBA keywords available to use for redefining for example spring.boot.admin.notify.mail.text Mail notifications configuration option?
I guess this is valid to other notifiers being hipchat, Slack.
Thank you.
The context for evaluating the SpEL expression is the event.
Therefore all properties from ClientApplicationEvent (or the corresponding subclass for the event instance (e.g. ClientApplicationStatusChangedEvent)) are available.
If it doesn't suffice you can ship your own subclass of the MailNotifier..
Answer is no, cannot do in current code base without code changes.
SBA notification keywords/variables available are the following:
application.name
application.id
application.healthUrl
application.managementUrl
application.serviceUrl
application.statusInfo.status
from.status
to.status
timestamp
type
We don't have anything else.
However the StatusUpdater.queryStatus looks promising to get some extra data.
I've got a Behringer X32 rack, which uses an extension of the OSC (Open Sound Control) protocol. This particular rack communicates via UDP packets on port 10023. A fellow named Patrick Maillot actually has some pretty extensive albeit unofficial documentation of the protocol, including multiple executables you can download to interact with the system (outside of the official Behringer apps).
What I would like to do is pretty simple, though I'm having a hard time getting up to speed with this. I want to be able to mute and subsequently un-mute Mute Group 1 on my device. The mute group is already set up; all I want to do is utilize the protocol to either activate or deactivate it.
I can successfully connect to the rack using the X32_Command.exe program. But wading through the documentation, here's what I came up with as my best guess for which commands I should be sending:
/config/mute/1/ON
/config/mute/1/OFF
However, I don't think I have the syntax right (or maybe I've just got the wrong set of commands altogether), because those don't seem to do anything. In the X32_Command.exe console application I appear to receive the following responses when issuing those commands, respectively:
->X, 20 B: /config/mute/1/ON~~~
->X, 20 B: /config/mute/1/OFF~~
However, nothing actually happens on the rack. The mute group isn't affected at all when I issue these commands. How do I get this working? What am I doing wrong?
Just saw this (better late than never). The correct syntax for X32_Commmand.exe would be (as stated in the documentation):
/config/mute/1 ,i 0
/config/mute/1 ,i 1
I would like for my iOS app when it is in background mode to execute at specific intervals some functions
(What I precisely want to do is to check a URL, and indicate its (int) content as a badge.)
However, I don't know how to have the function executed in the background.
Thanks.
Read about Executing Code in the Background. There is a limited set of things you can do in the background, what you describe not among them unfortunately.
I think you have two options to solve this problem each of them has pros and cons.
First, one is background refresh check the link. Have in mind that it is different for ios 13 and above. You need to define background tasks check here. It takes me some time to understand the background tasks but it seems more logical and easy to manage if you have several tasks. Still, you don't have the full control of when this task will be executed. It depends on how much battery, network and so on your task will use every time. The system will choose what is the best time to run it.
There is one more option, to implement a silent push notification check here.
Here you can implement a good push mechanism for updates but you will depend on network and permission for notifications. Also, you will need a backend for this solution.
You need to define what works best for you.
I think the best option is to use the voip background mode. Here you can find all the required information: how to run background process on the iOS using private APIs to sync email items without jailbreaking the phone
https://developer.apple.com/documentation/usernotifications/setting_up_a_remote_notification_server/pushing_background_updates_to_your_app
To update the content frequently when the app is in the background might be difficult, Instead, you can wake the app by pushing a silent notification from backend at regular intervals.
For more information check this article also
https://medium.com/#m.imadali10/ios-silent-push-notifications-84009d57794c
I was working on something for a client today when I found a way to break some functionality in our program.
(The code is really legacy code, it's been in development for about 10 years and I've only been working here for about a year.)
It didn't cause an error, or cause the program to crash, but if a user was using the program and duplicated the behavior I'm pretty sure they'd be holding up their "WTF?" flag.
In our program we have named fields (textboxes) and static text (labels) that can be linked with the textboxes. When the textbox is not filled in the label(s) that were linked to them disappear.
The functionality that I broke was, when you change the name of a textbox that already has one label or more linked to it, and save the file, without re-associating the one or more labels associated with the textbox, the formerly-associated labels appear when the textbox is blank.
Now my thinking on the matter is that a simple observer pattern could have solved this problem in the first place, but then I didn't write the code.
I was thinking that if I could dig up more situations like this with the guys in my shop, that maybe I could talk them into considering unit testing, decoupling, applying patterns where they are called for and the like.
So for this reason I was wondering if anyone had any tips for finding broken (but not error causing) functionality in any sort of app (web-based, desktop, etc...)
For an app to fail usability, it has to have a defined set of expected behaviors.
"Is this textbox SUPPOSED to do nothing when the enter key is pressed?" Maybe it is, maybe it isn't. I've seen apps where a tester/reviewer reports something that they ASSUME should work another way, when in actuality the client specifically asked that they DON'T want the form submitted on a return key press, but only a submit button click.
So basically you have to define proper behaviour before you can determine incorrect behavior.
Hire some testers.
If it has an interface, then one of my favorite unconventional test is putting 5-10 year old children in front of it. You'd be surprised what they can come up with (especially the younger ones). While this may sound like a joke, it isn't -- it really works, because children don't have the mindset of only going through "mindset" paths.
And yeah, children are the experts in "breaking things" xP.
Code inspections, i.e. reading the source code: if you had taken time to read/inspect the source code, looking for "smells" or even just looking for code whose behaviour you don't immediately understand and agree with, you might have been holding up your "WTF?" flag too.
Test, test, test.
Do unexpected things. Start doing one task and switch another to see if anything goes haywire. Use the back button when you're not supposed to. Open it in two windows. Let it time out.
Test in all browsers, especially IE.
You can find database connections/sessions aren't released by:
working out the minimum number of connections you need to do something
setting resource limits to that minimum number
ensuring one "run" of the scenario that should use exactly that number (and release it afterwards)
then run it again a few times... do you run out of connections?
I used to work in a company where programmers regularly used to forget to de-allocate db connections. The standard answer was to reduce the resource to a minimum to see if there's a leak - and to try to work out where it is by restarting the system and running different scenarios repeatedly.
The first hour of code review, with the first reviewer, will do the most to find quality problems. But here's the thing: You don't need to convince people of quality problems. You need to convince them of the value of fixing bugs, and of rewriting only when the present quality absolutely justifies it.
I've dealt with some seriously bad code in my time. But you can't just rewrite. You need a spec before you can even tell if the rewrite is an improvement.
Sometimes, you have to infer the spec from the code and then check it against some human somewhere. But by the time you've done that, you understand the code as written and are now better prepared to repair than to rewrite -- most of the time.
Repair proceeds by a process of small behavior-preserving modifications that render the spec more clear in the code. Then, when you find something that looks wrong, you don't just change it. You ask around until you find the person responsible for that decision, and you get them to show you where in the spec it says that behavior X is correct. (This conversation can take many forms.) If you're lucky, they'll tell you that behavior X is in fact incorrect, and then you've earned your pay.
assert()
Also unit testing with coverage analysis.
This is particular to the Visual Studio IDE, although it probably also applies to others:
During testing, always at some point run in the debugger with "Break when an exception is thrown" turned on.
This can often help expose exceptions which are incorrectly being silently caught and which represent bugs, but otherwise may not be evident.
Code reviews should always also include reviews of the unit test code.
The problem is that with ad-hoc testing it's impossible to know how much or how well a developer has tested their code. So, you're at the mercy of different developers definition of the word "done".
If you include reviews of the unit test code at the same time you review the production code you should have a good idea of whether the code is really complete; in that "complete" includes "tested". Not just "Hey, I'll throw it over the wall to the testers!".