Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Elevators

john.fun

Post reply on HN
Print view View original

251–260 of 426 posts

Re: Show HN: Elevators

#251

Post by userbinator »

cwillu wrote: post #242
Wowfunhappy wrote: post #203

All I want to know is why the heck I can't un-press a button I pressed by accident. This should be very simple. Press once to turn the button on, press again to turn it off. Or I guess you could do long-press to turn off or something if you're worried about confusing people, but I really don't think that should be necessary. We know how toggles work. The button lights up when it's on.

The most common control circuit has the button triggering a relay which then powers its own trigger until the circuit is interrupted elsewhere; this isn't compatible with the same button cancelling the call.

On the pop-out controls I mentioned in a sibling comment, the relay is the button, and you can pull it out to cancel.

Re: Show HN: Elevators

#252

Post by fragmede »

shepherdjerred wrote: post #241
pimlottc wrote: post #232

Earlier quoted context omitted.

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

I wonder if we'll see LLM elevator scheduling

IBM's Watson has been used for elevator scheduling.

Re: Show HN: Elevators

#254

Post by ImPostingOnHN »

wpm wrote: post #67
trivo wrote: post #25

Earlier quoted context omitted.

And then when the elevator door opens, they ask the people inside: "Are you going up or down?" There's an arrow showing that, for Christ's sake.

Yeah and you can flail your head around looking for the arrow or you can just ask. Especially on a busy elevator lobby there might be multiple cars opening at the same time so you cant even tell from the ding/ding-ding

or just point your eyes a few degrees away to look at the dedicated arrows next to each elevator, built for this exact use case, which indicate whether that specific elevator is going up or down?

I have to assume this is a cultural difference and you just don't have those indicators where you live, rather than "slightly moving my eyes is too hard, better make my problem into somebody else's problem"

Re: Show HN: Elevators

#255

Post by FabHK »

Wonder what would happen if the objective instead were to minimise sum of quadratic wait times (ie, penalise long waits explicitly).

Re: Show HN: Elevators

#256

Post by noisy_boy »

shepherdjerred wrote: post #241
pimlottc wrote: post #232

Earlier quoted context omitted.

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

I wonder if we'll see LLM elevator scheduling

I apologize for bringing you to the 29th floor instead of the 3rd floor as you requested. That's on me. I will do better next time.

Re: Show HN: Elevators

#257

Post by _kb »

pimlottc wrote: post #232
omoikane wrote: post #68

> Destination Dispatch [...] are in general worse I wonder if this is an artifact of how the author used random destinations. I worked in a building that used Destination Dispatch, and the common travel pattern seemed to be: - Everyone who is not on the ground floor generally want to go to the ground floor. - People who are on the ground floor generally travel in large groups to the same destination. This happens bec…

This is case where you need to make sure your test data reflects real-world usage or you end up optimizing for the wrong thing. Ideally a new elevator installation would have a trial period where they record usage and then run it through a simulator like this to determine the optimal strategy for that particular building. And you'd want to re-run it every once in a while as the building tenants/usage changes. I wonde…

The data is already there. This also gets more interesting when you expand the scope from just elevators to general building occupancy and movement.

In the simplest sense, I've seen this tied into security gates so as people badge on when entering the building there's already suitable elevator movement to meet demand by time the foot traffic reaches the lift lobby. That can then also feed into destination dispatch if you move from just people counts to identity (and known/most likely work floor).

From there you can move into wifi trilateration and have a live and quite accurate view of both how and who interacts with a physical space. This can feed into HVAC load shedding, JIT bookings for meeting rooms or workspaces, and a lot of very good things from a sustainability and general optimisation perspective. The flip side is it also has the potential to be an absolute dystopian privacy nightmare.

Re: Show HN: Elevators

#258

Post by ImPostingOnHN »

fragmede wrote: post #226
cyberax wrote: post #116

Earlier quoted context omitted.

Modern elevators have regen braking, so they can recover most of the energy spent on going down. Older elevators used braking resistors for that. (BTW, going _down_ while empty is typically more energy-consuming for the elevators because they are counterweighted) Edit: that's also why you shouldn't use elevators in a fire. If the brakes in the elevator machine room fail, the cab won't crash down. It will go _up_, pos…

Interesting! It's counterbalanced though, so why does it go up if the brakes fail in a fire? That's counterintuitive.

Maybe it needs to be counterbalanced at maximum approved elevator+load weight?

Re: Show HN: Elevators

#260

Post by ImPostingOnHN »

oliv__ wrote: post #240
psadri wrote: post #130

Aside for the algorithms and how well they work, there is a psychological aspect to how people perceive "wait" times. It turns out just waiting is very annoying. But having people do anything during that same wait period → perceived as progress → not upset. An example iirc was waiting for luggage at the airport. It takes min of x minutes for the first bags to show. In one version, passengers went directly from the ga…

I don't see how that's perception then? It was just made inefficient on purpose. If I have to walk to the luggage area 10min and wait another 10min for my luggage it's not the same as if i walk 5min to the luggage area and wait 15min for my bag. Yes, total time is the same but one scenario is acceptable because it feels inevitable and is under control (cannot personally move across space/time faster) the other is not…

The perception angle is: customers are less unhappy waiting the required 20 minutes for luggage to show up, if they're doing something else during that time.

In this example, the passengers are still waiting while moving (the wait for luggage is 20 minutes either way), they just don't perceive that portion of the waiting as intolerable.

Bringing it home to elevators, the situation is pretty much the same, only in reverse: someone who waits 2 minutes for an elevator and 1 more once aboard it to get to their floor, likely perceives their 3 minute total wait as less tolerable, than if they waited 1 minutes for the elevator plus another 2 once aboard.

Post reply on HN