Closed afewremarks closed 10 years ago
Thanks, Mark!
This looks really good. I've made a few changes in the latest commit. JSHint passes, but I don't have a device to check that it actually runs as expected.
I'm not super familiar with the device - but for most, I've been able to poll them by making a connection but not sending any command. I do this on an interval that's called automatically if you have a state() method in your controller. This is used to update the interface to gray it out if the device is not on. I may add that later.
Ok I will see if I can figure that out. This is the function that is doing that correct: "state : function (controller, callback, config) ". I see it in the controllers does it exist anywhere else?
I can add it tonight - it's no biggie. Basically, for any controller that has a method of "state", the events/schedule.js will call that method every defined interval (set in the config - defaulted to 5 seconds, I think). The callback sent to the state() method expects either a response or a failure. It then calls the deviceState object to update the state with the current state - adds on a "last known" timestamp and checks if the state has changed and dumps that into the global State object. If state has changed, it pushes that one device's change to all connected WebSocket clients. If you're doing polling, the change will show up on the next poll. Once the change is received at the client, the interface is updated through the parser. The one parser file is shared between client and server (but compiled for client side). The Samsung parser, state() method and template are a good example of a simple polling for device state.
Gave it a try but doesn't seem to be working correctly. Terminal is outputting line 144 from pioneer.js
https://github.com/afewremarks/universalController/commit/3222e8f4ea7eecc81d9bddfb37e526d7e1487b35
I'm not getting any error there. Granted, I don't own a device - but I'm getting the expected "EHOSTUNREACH" error.
Ahh - okay, found the issue (I think). There's a "hashtable" which just translates pretty names to the gibberish some devices are expecting. That's just for convenience and easier reading.
The "keymap" is a whitelist of expected command types. It serves as a reference to anyone that wants to build their own interface as a place where they can see all available commands - but it also serves as a whitelist to ignore any (potentially sketchy) commands that are received but not expected.
thanks for your help. The status() part still isn't 100% functional but i think I understand all the elements but one now. I am struggling to grasp what and where in the code the test actually happens. Is it just pinging the ip or it actually trying to send one of the actual commands in the whitelist? If I get a hint there I think I will be able to figure it out :)
The schedule.js passes along a generic callback to the "state()" method within a controller. This generic callback simply takes the response ("err" or "ok") and uses that to update the global State object. There's no command sent - it just expects a device reply confirming the connection: https://github.com/imbrianj/switchBoard/blob/master/events/schedule.js#L42
and this is where it's called: https://github.com/imbrianj/switchBoard/blob/master/controllers/pioneer.js#L95
It could be that you don't get a reply at all (or something falsey) and that condition may fail. It may be worth just trying:
if(err) { callback(pioneer.device.deviceId, 'err'); }
else { // assume all is ok callback(pioneer.device.deviceId, null, 'ok'); }
Hmm ok still having issues. The scheduled status checks are only returning these two lines alternating for pioneer:
https://github.com/imbrianj/switchBoard/blob/master/controllers/pioneer.js#L124 and https://github.com/imbrianj/switchBoard/blob/master/controllers/pioneer.js#L138
My guess is its something to do with the fact that this thing communicates over telnet via specific port?
I just made a commit - can you fetch upstream and see if that solves it? There were two issues: 1) I somehow forgot to add teh pioneer callback to set the State and 2) We probably don't need to print an error of no command sent.
Bingo that did it! Thanks for your help/patience. Other thing I had to do was change the polling interval to 20 seconds or every other state check fails.
Hi Brian,
I have the pioneer code working now. Been running it for a few days and no issues. You are able to select an input, power on/off, turn vol up/down and mute everything. I will work on adding more relevant functionality but for now this base enough for users to get use out of it.
-Mark