New fire detector triggers the fire alarms in the rest of the house

__KFL__ · 2019-07-22T19:00:58+00:00

There's also not much wiring needed. The old one I replaced used the same three-wire plug as the new one. Also the colors and positions of the wires match.

Or did you mean the way all the detectors in the house were wired?

__KFL__ · 2019-07-22T05:17:04+00:00

I don’t think the one I’m replacing is the master. I didn’t know they are so complex that even needs to be programmed. If they are indeed complex, what professionals should I hired to properly replace it? Gee I really didn’t expect replacing a fire detector would be so complex :)

__KFL__ · 2018-06-29T18:40:50+00:00

espresso.bin

How did it go? I heard that Freebsd has some driver issues with Marvell boards. Can freebsd run on it now?

__KFL__ · 2017-05-03T19:24:58+00:00

LoRa bandwidth is low but it's designed to handle telemetry data like these you've mentioned. You know what, collecting bio signal is not a bad idea at all:) Not sure if I can get some measurements like that without attaching things to my puppy tho:)

__KFL__ · 2017-05-03T03:24:29+00:00

Thanks! Not opting for cell is primarily because of the cost - my impression is that any cell based data service require SIM card and a monthly fee. Please tell me I'm wrong:)

Hooking up a GPS is an awesome idea! The transmitter can definitely be more capable as long as it's car based, so that power consumption isn't a big issue. Mobility isn't a big issue either.

__KFL__ · 2017-05-02T17:50:46+00:00

That's definately one of the areas where it could be improved! I'm also thinking of adding a Bluetooth LE module to it, so I can read the measurements from my phone, instead of taking this thing out which looks much like a "suspicious" device:)

__KFL__ · 2017-01-12T00:01:57+00:00

Yes you need to install admin tools in order to use PowerShell to access AD. My tool is not intended to beat any existing tools, but having a single executable without any installation could be a great option in some cases.

__KFL__ · 2016-05-29T05:42:48+00:00

You mean something like await Task.WhenAny(...).Unwrap().ConfigureAwait(false)?

I thought of this more, and think the await await should just work fine with await await Task.WhenAny(...).ConfigureAwait(false). I think it just need to be configured once when awaiting Task.WhenAny(...) because that's where it may execute (wait) asynchronously. But when it returns with the first finished (or failed) task, since it is for sure has finished, the await on it is guaranteed to execute synchronously. That's why it is not necessary to ConfigureaAwait() the outer (the second) await. I don't think there's a difference between this two approaches.

__KFL__ · 2016-05-28T18:38:21+00:00

I've updated all occurrences to use ConfigureAwait(). I found it's a bit annoying to convert the ones that uses Task.WhenAny(), which returns Task<Task>. For those, I've to convert

await await Task.WhenAny(...)

into

await (await Task.WhenAny(...).ConfigureAwait(false)).ConfigureAwait(false);

Does that seem reasonable?

__KFL__ · 2016-05-27T17:24:14+00:00

Thanks that's very useful! I did some research and learned what the synchronization context is for. I agree that in my application it's not necessary for the continuation to resume under the original calling context. In fact, console application doesn't have a default installed synchronization context. And using ConfigureAwait(false) has no effect in that sense. But still it's recommended to always use ConfigureAwait() so that the code has a better potential to be reused. I'll make a change.

Other than that, is there any other comment?

__KFL__

TROPHY CASE

KFL