So you're a Noob? Post your questions here until you graduate! Don't be shy.

User avatar
By Narfel
#71886 Thanks for putting up with me, i begin to realize that i basically dance around the same question in different threads. If we ignore the "wrongness" of the handlePhysicalButton() in the loop for a second, in the output you quoted can you think of any reason those messages should not reappear in the console when i do a site reload (thus calling start(), creating a new websocket connection and listen, intercept and print those messages)? I'm asking because before continuing i would like to understand the 50:50 chance of it looping (and therefore all hardwarebutton feedback). And my understanding on creating/closing the websocket connection from the browser hinges on that.

On the javascript side I created a check for any possible readystate of the websocket connection with a callback to wait and a open/close for the websocket and put some printouts in the console. That's a bit overkill, but at least it kinda works. It still doesn't lift the mystery of the handlePhysicalButton() loop playing hard to get.

Code: Select allfunction sendMessage(msg){
      // Wait until the state of the socket is not ready and send the message when it is...
      waitForSocket(websock, function(){
          console.log("sendMsg(): (" + msg + ")");
          websock.send(msg);
      });
  }

  // Make the function wait until the connection is made...
  function waitForSocket(websock, callback){
      setTimeout(
        function() {
             switch(websock.readyState) {
                 case 0:
                  console.log("websock.readyState = " + websock.readyState + " - The connection is not yet open")
                      console.log("Waiting for connection...")
                      waitForSocketConnection(websock, callback);
                  break;
                 case 1:
                  console.log("Case 1: websock.readyState = " + websock.readyState + " - The connection is open and ready to communicate")
                      console.log("Connection is made")
                      if(callback != null){
                          callback();
                      }
                  break;
                case 2:
                  console.log("websock.readyState = " + websock.readyState + " - The connection is in the process of closing.")
                      console.log("Waiting for connection...")
                      waitForSocketConnection(websock, callback);
                  break;
                case 3:
                  console.log("websock.readyState = " + websock.readyState + " - The connection is closed or couldn't be opened.")
                      console.log("Restarting Websocket...")
                      start();
                  break;
                default:
                      console.log("¯\\_(ツ)_/¯");
             }
        }, 1000);
User avatar
By rudy
#71888
Narfel wrote:If we ignore the "wrongness" of the handlePhysicalButton() in the loop for a second,


I don't think it was wrong. More typical than not I think. Sure there are other ways of doing it.

in the output you quoted can you think of any reason those messages should not reappear in the console when i do a site reload (thus calling start(), creating a new websocket connection and listen, intercept and print those messages)?


A reload is the same as a new connection. Whatever happens when the page starts for the first time should happen again with a reload.


I'm asking because before continuing i would like to understand the 50:50 chance of it looping (and therefore all hardwarebutton feedback). And my understanding on creating/closing the websocket connection from the browser hinges on that.


The modified code I posted does a broadcast to all connected clients when the button changes the led state. My code doesn't know if there are connected clients or not. It just passes the information to the library and it seems to handle it.

On the javascript side I created a check for any possible readystate of the websocket connection with a callback to wait and a open/close for the websocket and put some printouts in the console. That's a bit overkill, but at least it kinda works. It still doesn't lift the mystery of the handlePhysicalButton() loop playing hard to get.


I'm not sure what you mean. Tell me what you want to happen from the user perspective, how the device is to react to user input. And if it doesn't do what you want then tell me where it fails. I need to understand the problem before dealing with the details. Like I said earlier, I'm not a programmer and my experience with this stuff is limited, but growing.
User avatar
By Narfel
#71894 @rudy: Your code runs flawlessly, whereas mine was build on a wrong premise. I'm not sure if i can explain a faulty premise now that the problems where pointed out to me. The whole "loop" idea was based on me not knowing how to get the hw button to send a message other than having the function send the message 'ledon' or 'ledoff' looping all day long and having the websocket check it for a change. If it sounds silly that's because it is 8-) ;)

I think this clunky implementation was causing most if not all the primary problems i ran into with the console, sockets closing and overflows. That's not to say that i'm safe from caching issues and the likes, but its a lot to process now that i know i had two issues i thought were one.

Big thanks to you both, can't say that enough.
User avatar
By rudy
#71895
philbowles wrote:
rudy wrote:A reload is the same as a new connection. Whatever happens when the page starts for the first time should happen again with a reload.


Sadly not always true.

Yes you are right. I meant with simple code as I posted.

I was recently reading up on mDNS and it's design. Simplicity (or as simple as possible) so it can work without the planets having to be in alignment. And there was a quote that was something like, "You know that you are done when you have removed everything that is absolutely not necessary." This was by an early aircraft designer but the same approach was desirable when designing a protocol. KISS

@Narfel This stuff isn't easy. But it gets easier as time goes on.