bottleneck
Choose style:

Author Topic: Any feedback or questions related to Web Socket API  (Read 9462 times)

0 Members and 1 Guest are viewing this topic.

Offline SecureComp

  • Backer
  • *
  • Posts: 541
  • Thanks: 1
  • Registered : 05/08/2014
    YearsYearsYearsYearsYears
Re: Any feedback or questions related to Web Socket API
« Reply #30 on: February 10, 2016, 10:18:01 pm »
good stuff @fort

Seeing the same things, handling the case sensitivities isn't a big deal, just tedious.
Using the same solution and declaring two variables at times when really one should be enough. (mii)

Wondering whether the to send "true" "false" or 1, 0 has tripped me up a few times.

Fixing these items and a few others would speed up development just because I wouldn't be chasing down issues but I do understand the level of effort that would need to happen on Securifi's part as well.



Kickstarter Backer
Securifi Wiki Editor and Beta Tester, Not a Securifi employee
Almond+, many sensors, IOS App, Android Apps and Widgets

Offline Ashok

  • Securifi Staff
  • *
  • Posts: 2738
  • Thanks: 3
  • Registered : 25/07/2014
    YearsYearsYearsYearsYears
Re: Any feedback or questions related to Web Socket API
« Reply #31 on: February 11, 2016, 07:42:21 am »
@ fort,

Incomplete documentation

This is somewhat expected seeing as the API is all shiny and new. It's cropped up mostly when I'm looking for a list of acceptable values for a particular parameter. For instance, I was trying to activate a specific rule, so I sent the following:
Code: [Select]

 "mii":"<random key>",
 "cmd":"validaterule",
 "ruleid":"<ruleid>",
 "value":"true"
}

Well, this didn't work. Turns out, the value attribute was expecting either a "1" or a "0" even though the response data shows "true" or "false" (ex: "data":{"value":"true","ruleid":"<ruleid>").


Yes, that is what the command expects either 1 or 0.


Structural weirdness (possibly typos?)

Here's the sample request for ActivateScene:
Code: [Select]

 "CommandType":"ActivateScene",
 "MobileInternalIndex":"324",
 "Scenes":{ 
   "ID":"11"
 }
}

Should the "Scenes" attribute be an array?


Yes, it is in Array format, however, we will not allow multiple scenes at a time.

Offline fibrs86

  • Backer
  • *
  • Posts: 4
  • Thanks: 0
  • Registered : 12/08/2014
    YearsYearsYearsYearsYears
Re: Any feedback or questions related to Web Socket API
« Reply #32 on: February 13, 2016, 11:47:08 am »
Since this websocket is completely insecure, I assume/hope it is only exposed on the internal interface.

Is the intention to keep it local network only, even if it is secured?

Offline bmwilson55

  • Newbie
  • Posts: 2
  • Thanks: 0
  • Registered : 27/12/2018
    Years
Re: Any feedback or questions related to Web Socket API
« Reply #33 on: December 27, 2018, 02:49:55 pm »
Hello all.  Trying to access the websocket on my almond 3 using the chrome simple web socket client.  Which/what password do I need to use in the URL?  Is it the same password to access the local web interface?  Thanks

Offline cr0ybot

  • Newbie
  • Posts: 2
  • Thanks: 0
  • Registered : 09/01/2019
Re: Any feedback or questions related to Web Socket API
« Reply #34 on: January 16, 2019, 11:29:07 pm »
@bmwilson55 If you haven't found the answer by now, you need to use the username & password for the local web interface.

I'd love to see some explanatory text added to the DeviceList doc. The Websockets API doc is not very helpful with regards to knowing what "Type" values map to what "Device" with specific "DeviceValues" (capabilities). In fact, I glossed past the sections of the websockets doc most relevant to me because I didn't grok that a "DeviceIndex" is how we're supposed to interact with and read/change a devices properties.

There's an entire column for "Remarks" that is just begging for some explanations. For starters, what do the 5 different values for DoorLock LOCK_STATE symbolize? I'm assuming something along the lines of open, closed, opening, closing, and maybe unknown, but I don't have a lock to test with and they are unlabeled in the doc. Also, what are the practical differences between the data types Byte, Int, Decimal, Unsigned-Char, and Unsigned-Char(Decimal) when the value ranges seem almost interchangeable? I'm familiar with the usual difference between, say, a byte (8-bit, 0-255) vs an integer (at least 16-bit, 0-65,536), but I see a lot of interchangeable types (Byte, Decimal) for number ranges of 0-255 and 0-100.

Why are my non-colored Hue bulbs showing up as Type 4 (MultilevelSwitchOnOff) with extra undocumented device values that correspond with Type 48 (HueLamp) but in a different order? And is there any documentation on the Type values associated with each DeviceValue?

And what are all the references to XML about? The websockets API is JSON, is there another API that handles XML? Is there documentation on the XML that may have more information?

I might be interested in edit rights for the Wiki while I develop my addon for Mozilla's Things Gateway: https://github.com/cr0ybot/almond-adapter

Offline Square Cherry

  • Backer
  • *
  • Posts: 29
  • Thanks: 0
  • Registered : 20/08/2014
    YearsYearsYearsYearsYears
Re: Any feedback or questions related to Web Socket API
« Reply #35 on: January 18, 2019, 03:10:59 am »
cr0ybot,

I've had to figure a lot of these things out myself in rewriting a homebridge-almond plugin. You're welcome to look at how I interpreted the Almond's JSON values. Particularly, the GarageDoorOpener and DoorLock states needed a lot of trial-and-error. There are still a bunch of device types I haven't tackled yet, as I only have so many sensors on hand. Pardon my disdain for semicolons. ;)
« Last Edit: January 18, 2019, 04:20:00 am by Square Cherry »
Andrew

Offline cr0ybot

  • Newbie
  • Posts: 2
  • Thanks: 0
  • Registered : 09/01/2019
Re: Any feedback or questions related to Web Socket API
« Reply #36 on: January 18, 2019, 03:28:30 pm »
@Square Cherry your work will be an invaluable reference, thank you! I may be interested in using your almond-client as a dependency, though I see your edits have not been merged upstream to the npm-connected repo. I've already got the websocket connection working, but this looks like it has many useful features and it would be silly to duplicate the effort.

 

Page created in 0.038 seconds with 21 queries.

bottleneck