|
Chrome 73.0.3683.103 here, and it's working fine, as well as other browsers.
I downloaded the video (youtube-dl) and loaded it with Avidemux - it's not seeing anything out of the ordinary.
Slick logo, BTW.
|
|
|
|
|
I can't take credit for the logo. I'm just using it.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
I suspect the gubment IT gremlins.
Software Zen: delete this;
|
|
|
|
|
The world is coming to an end, folks... John's gone Hollywood. 
Software Zen: delete this;
|
|
|
|
|
When I'm done with the prototype demo(s), I'm gonna start doing code varticles. I already have some intro stuff ready.
|
|
|
|
|
It looks pretty good. There are a lot of artifacts from heavy compression but I don't know if you can do anything about that.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
i guess i could try a different codec/container, but i'm not a video expert, and i don't know what youtube does to videos after you upload them. I uploaded it at 1080p. I think you need to go full screen to see it as intended.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
So a demi-rant... Why don't people get that REST sucks for a wide variety of applications. Being in the automation world I run into this problem a lot. People make a device, and probably make no effort to ask anyone like me what are needs are, they put a web server in it and design a simple REST API.
The problem is that automation systems are fundamentally dependent on low latency awareness of changes in the state of devices, because users set up systems like ours to react to those changes. If it doesn't happen for a second or two after the actual change, then it's often useless or at best annoying.
So now you have a a bunch of devices out that that you just have to pound relentlessly with GET commands in order to try to catch any changes in a reasonable amount of time. And then of course they get the bright idea to make it 'easy' by only allowing the transfer of the entire state of the device (like the Hue), so you have to transfer the entire state of the device multiple times a second in order to catch a change that might not happen for many hours or even days at a time, but has to be caught quickly when it does.
And, then the customer has some other thing that also needs to do the same, so it's pounding the same device relentlessly and now the device is overloaded and starts responding more slowly in general, or crapping out periodically.
It's like so many people just don't even think beyond a REST API or HTTP, and throw it into everything, whether it's remotely appropriate or not.
Explorans limites defectum
modified 18-Apr-19 14:37pm.
|
|
|
|
|
There there.
I agree. It sounds like the device should be the client rather than the server. It should use REST to send data a Web Service.
modified 18-Apr-19 20:03pm.
|
|
|
|
|
You generally don't really want to go that direction for security purposes. The automation controller should always be the one that makes the connection if at all possible.
Explorans limites defectum
|
|
|
|
|
So, what's the solution?
An x second timeout on a GET that only returns when the underlying data has changed?
(Almost like a remote event handler?)
|
|
|
|
|
Don't use HTTP is one obvious one. Or, if you do, follow the ISY example and send async responses over a persistent connection.
Explorans limites defectum
|
|
|
|
|
I agree that REST seems like a poor choice for low latency.
Just a thought - latency can be reduced by using more modern frameworks that while they do serve the entire state initially only subsequently serve the elements of the state that have changed or use SignalR.
On the area of latency - even if you do use a protocol that is less data intensive than REST, if you are not using a private direct network connection your latency will surely always be at the mercy of things that are out of your control - or have I misunderstood what you are saying?
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
It's not up to me, we are at the mercy of whatever the device manufacturer decides to do. Of course TCP/IP in general is a bad choice for most small automation doo-dads, but since it's the defacto, ubiquitous connection scheme that is going to be in there in the home, more and more companies use it. It's always the same, unplanned, excremental growth leads to the worst case scenario becoming the standard scenario so often.
The only device that uses HTTP well (that I've run across) is the ISY 994. It uses a persistent HTTP connection and just asynchronously sends notifications as GETs to the automation system when something changes. If you are going to use HTTP, that's how it should be done.
There are other simple schemes that work well. One is to keep a running 64 bit serial number. Every time a value is changed, bump the serial number and set it on that value. Keep a sorted list of such changes (Which is simple and efficient to do, push each one onto the top of a stack when it changes, if it's full dump the bottom one.)
When a client asks for changes, they pass the last serial number they got (zero if none yet), and the device can just find that number in the list (binary search since it is sorted by serial number), and returns him anything from there forward. If the number is below the bottom, he returns an error saying 'sorry you have to do a full resync'. If it works, the automation system just stores that returned serial number as the last one it got, and passes it back next time. The majority of queries just return a very small 'no changes' status since the serial number passed is the same as the one on top of the stack.
I use this type of scheme to VERY good effect in CQC in a number of places. My ORB supports it as well, with a special 'poll method' that takes a serial number as the first parameter and returns a boolean. If the serial number is the same as the handler on the server side, then it returns false and the server side ORB knows it doesn't have to stream back any of the output parameters.
Explorans limites defectum
|
|
|
|
|
|
Dean Roddey wrote: Of course TCP/IP in general is a bad choice for most small automation doo-dads
This is out of my level of experience however I am aware that UDP is an alternative in this sort of thing.
However the issue with UDP is that there is no concept of packets being dropped or guarantee that what gets sent from the server will get to the client in once piece - see what I mean about 'out of my level of experience", I almost started referring to the interwebs as a series of tubes.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Actually I meant IP in general. Most home automation stuff should be on a dedicated backbone, like Zigbee (or in the case of some of the higher end stuff like Lutron, they are on proprietary wired or wireless protocols.) These are purely local systems that cannot be attacked by every scumbag on the network.
Some stuff needs higher bandwidth than that, and they are OK using TCP/IP if well done and most of the pro level stuff is. A lot of consumer stuff very much isn't. For instance cameras generally need to be on the local network for video streaming purposes, but they are horrible security-wise in general. There's been so many security issues reported with them. And all these small companies doing little IoTs doodads probably don't remotely deal with security in any comprehensive way. They are probably struggling to get the product done before they run out of money.
You really need to cordon off that stuff on a separate LAN to be safe, but then of course they can still be used in DOS attacks unless you prevent them from making outgoing connections. And your average user isn't competent to do either of those things.
Explorans limites defectum
|
|
|
|
|
I think you need to give it a rest...
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
One of the better rants I've come across.
I think in general you are ranting about :
Design Versus Defaults!
In other words, why do people supposedly design devices that are not actually designed at all but are just knee-jerk reactions to a problem.
Someone recently told me they he "Finally got my garage door set up on wifi. It took me a long time though.".
I shivered a bit as I imagined his garage door being opened by random hackers on the Internet.
It makes no sense to create a garage door opener that uses wifi and connects to the Internet.
He also mentioned that it takes a bit for his phone to connect to his wifi anyways so it takes a while to use it each time.
But many manufacturers just default to wifi when they should just use local wireless like bluetooth.
I created such a device and it was really quite easy and very inexpensive (Never Buy A Garage Door Remote Again: Open Your Door With Your Android Phone (via Bluetooth)[^]).
Also, even if you want to know if your garage door is up or down from a remote location that is still possible without forcing the user to connect his garage door to the Internet.
Well, that is design by default instead of design through thinking and choosing the proper devices and services.
|
|
|
|
|
Oh, the whole home automation thing, as it has become in recent years, is just a security nightmare, no doubt. All these small doo-dads from China that people just plop inside their local network and they are connecting to who knows what, or being infected and used in massive DOS attacks and such.
The thing is, a lot of these newbies will shat on serial connections as old fashioned, but they are inherently safe, point to point connections between the automation system and the device. As long as the bandwidth is sufficient and the devices relatively close (and often they are) then it's an excellent connection type to use (and very cheap for the manufacturer.)
But of course most of these newer companies are not interested in that, they are interested in tying customers to their cloud-based services so that they can collect data and monthly fees. And many of them don't look beyond their own phone based app control interfaces, so we end up going back to the start except that now there are a bunch of virtual remote controls on a phone instead of a bunch of real remote controls on a coffee table.
Explorans limites defectum
|
|
|
|
|
raddevus wrote: One of the better rants I've come across.
PFFFFT!!! He ain't serious unless he's said "f*ck" at least once.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Gosh darn the blankety heck.
Explorans limites defectum
|
|
|
|
|
|
|
We go through that sort of thing occasionally, as we build commercial ink-jet printing systems. I can't imagine anyone using some godforsaken web protocol for command/status in any kind of process control environment. All of our peripheral systems use TCP/IP socket communications, usually over a gigabit private Ethernet.
Given that we're running paper at up to 17 feet per second, half-second latency turns into a lot of paper.
Software Zen: delete this;
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
