Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 6 FirstFirst 1234 ... LastLast
Results 11 to 20 of 55
  1. #11
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    227
    After reading all your advice I moved on and got some communication with my hue ;o)

    Now I am trying to use c-functions. The reason is that I want to make it easy to implement the commands for the hue.
    I thought of providing one function for sending the HTTP requests using curl. Others, one for each command shall prepare the command in JSON and parse the response.

    Now I ran into an issue.

    Therefore, I did a function called "HueIssueRequest". The function is defined as:
    Code:
    bool HueIssueRequest(struct sMR *Device, hue_cmd_method connectMethod, char *uri, char *jsonRequestBody, char *jsonResponseBody)
    {
        ...
        strcpy(jsonResponseBody, cf->payload);
        ...
    }
    "jsonRequestBody" is sent to the hue and "jsonResponseBody" is the answer.
    The response is taken from curl. It is returned inside "cf->payload". I try to copy that to "jsonResponseBody".

    Another function called "HueCheckConnect" is concerned with preparing the JSON stuff, sending the command via "HueIssueRequest" and shall then parse the response in "jsonResponseBody". So the idea.
    The function is defined as:
    Code:
    bool HueCheckConnect(struct sMR *Device)
    {
        ...
        char *jsonResponseBody;
        HueIssueRequest(Device, HUE_METHOD_GET, uri, jsonRequestBody, jsonResponseBody);
        ...
        LOG_SDEBUG("Response Body: %s", jsonResponseBody);
        ...
    }
    It simply contacts the hue calling HueIssueRequest.

    The problem: The LOG_SDEBUG shows:
    Code:
    Resonse Body: (null)
    The complete code can be found here: https://github.com/chincheta0815/Hue...eeze2hue/hue.c

    The lines I mentioned are:
    - Reassigning from payload to jsonResponseBody: https://github.com/chincheta0815/Hue...hue/hue.c#L197
    - Working with jsonResponseBody in the calller function: https://github.com/chincheta0815/Hue...hue/hue.c#L228

    It seems that I am messing up with pointer, etc. How can I get that working? Is there maybe some better way to make that modular?

  2. #12
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,204
    Quote Originally Posted by chincheta0815 View Post
    After reading all your advice I moved on and got some communication with my hue ;o)

    Therefore, I did a function called "HueIssueRequest". The function is defined as:
    Code:
    bool HueIssueRequest(struct sMR *Device, hue_cmd_method connectMethod, char *uri, char *jsonRequestBody, char *jsonResponseBody)
    {
        ...
        strcpy(jsonResponseBody, cf->payload);
        ...
    }
    "jsonRequestBody" is sent to the hue and "jsonResponseBody" is the answer.
    The response is taken from curl. It is returned inside "cf->payload". I try to copy that to "jsonResponseBody".

    Another function called "HueCheckConnect" is concerned with preparing the JSON stuff, sending the command via "HueIssueRequest" and shall then parse the response in "jsonResponseBody". So the idea.
    The function is defined as:
    Code:
    bool HueCheckConnect(struct sMR *Device)
    {
        ...
        char *jsonResponseBody;
        HueIssueRequest(Device, HUE_METHOD_GET, uri, jsonRequestBody, jsonResponseBody);
        ...
        LOG_SDEBUG("Response Body: %s", jsonResponseBody);
        ...
    }
    Be careful, you're having a pointer issue, in HueCheckConnect, the jsonResponseBody pointer is not initialized. You're passing that pointer as a parameter to HueIssueRequest which copies at the pointed address the cf->payload. This means you're copying a string to an unknown address (it should create a fault, I'm surprised it does not).
    You either allocate the memory for jsonResponseBody before you call HueIssueRequest or take it from the stack, if you're sure of the max size of this payload. Or you pass a pointer to the pointer in HueCheckConnect

    Code:
    bool HueIssueRequest(struct sMR *Device, hue_cmd_method connectMethod, char *uri, char *jsonRequestBody, char *jsonResponseBody)
    {
        ...
        strncpy(jsonResponseBody, cf->payload, MAX_BODY_SIZE - 1);
        jsonResponseBody[MAX_BODY_SIZE - 1] = '\0';
        ...
    }
    
    bool HueCheckConnect(struct sMR *Device)
    {
        ...
        char jsonResponseBody[MAX_BODY_SIZE]; 
        // or char *jsonResponseBody = malloc(MAX_BODY_SIZE);
        HueIssueRequest(Device, HUE_METHOD_GET, uri, jsonRequestBody, jsonResponseBody);
        ...
        LOG_SDEBUG("Response Body: %s", jsonResponseBody);
        ...
    }
    or (and I prefer that personally)

    Code:
    bool HueIssueRequest(struct sMR *Device, hue_cmd_method connectMethod, char *uri, char *jsonRequestBody, char **jsonResponseBody)
    {
        ...
        *jsonResponseBody = strdup(cf->payload);
        ...
    }
    
    bool HueCheckConnect(struct sMR *Device)
    {
        ...
        char *jsonResponseBody 
    
        HueIssueRequest(Device, HUE_METHOD_GET, uri, jsonRequestBody, &jsonResponseBody);
        ...
        LOG_SDEBUG("Response Body: %s", jsonResponseBody);
    
        free(jsonResponseBody);
        ...
    }
    Last edited by philippe_44; 2017-04-17 at 20:24.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  3. #13
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    227
    Many many thanks, I think I'd never figured that out.
    That is one of my bigggest problems: Coping with stings in C. I know that they are special, but I always run into those allocation problems...

    I played a lot around with the plugins on the weekend and now I think I got a good overview of what I need and what I can adapt for my one. It would be great to hear your profound judgement...

    The parts I need for steering a hue are:
    1. UPNP just for the discovery,
    2. HTTP-Requests and -Responses for steering the lights,
    3. in some time in the future a sound stream analyzer and maybe transcoder
    What I do not need: a server sending a stream to the hue.

    Matching that to your plugins I think the squeeze2cast covers most parts:
    1. It discovers the chromecast via mDNS (changeable, to be taken from squeeze2upnp),
    2. Steers the chromecast via HTTP-Requests and -Responses (needed),
    3. Does fancy stream stuff (needed in parts, to be taken from squeeze2roap).

    Is that correct?

    If yes:
    I can leave out the webserver.c, the upnp webserer & the upnp virtualdirs. Theses seem to simply send the sound stream.

    The HTTP-Requests for interacting with the cast are send in a chromecast stream, the socketID is stored as a attribute of the player (somewhere in the files concerned with castcore.c).
    The Responses seem to be handled in the squeeze2cast.c via GetTimedEvent.

    I am asking to identify where the requests are sent and where the responses are processed. Once I have that I think I can start the show.

    A more sideshow question: Is there a bridge similar to shairtunes that exposes LMS as a chromecast for streaming with android sound to it. Usage would be: hit the chromecast button in an app, select the lms-chromecast & enjoy.

    I would then use the routines in squeeze2cast together with jansson as this seems to be quite lightweight...
    Last edited by chincheta0815; 2017-04-18 at 04:20.

  4. #14
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    227
    May I ask you for a favor? Could you explain in very few words what the following functions in squeeze2... do?
    - SyncNotifState
    - RefreshTO


    In squeeze2upnp.c?
    - ProcessQueue
    - HandleStateEvent

    And what does the "itf" in some headers mean?

    Another 2 thing that may help me:
    - Looking into squeeze2cast: What is the difference between the media renderer and the Cast? Is the media renderer some internal software stuff?
    - How would you send the request and receive a response? Directly after issuing the response in the same function? I do not want to block my sockets...

    I simply want to know if I need them...
    Last edited by chincheta0815; 2017-04-18 at 13:01.

  5. #15
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,204
    May I ask you for a favor? Could you explain in very few words what the following functions in squeeze2... do?
    - SyncNotifState: It handles the messages received from the UPnP player and changes its state accordingly, it takes necessary actions and using sq_notify informs the "squeezelite size". No need on your side.
    - RefreshTO: Refresh timeout is used to detect players that disapear (reset the timeout). You should leave this one

    In squeeze2upnp.c?
    - ProcessQueue: messages sent (some of them) to upnp player are queued to make sure that previous message is ack before sending next one. this function just un-queue the next message
    - HandleStateEvent: the bridge has subscribded to UPnP event change notification. This one just handle volume change made locally on the player. You don't need that

    And what does the "itf" in some headers mean?: interface

    Another 2 thing that may help me:
    - Looking into squeeze2cast: What is the difference between the media renderer and the Cast? Is the media renderer some internal software stuff? : no, I just did not "translate" everything.
    - How would you send the request and receive a response? Directly after issuing the response in the same function? I do not want to block my sockets...
    Yes. You shall use select() to check for socket availability

    I simply want to know if I need them...
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  6. #16
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,204
    Quote Originally Posted by chincheta0815 View Post
    Many many thanks, I think I'd never figured that out.
    That is one of my bigggest problems: Coping with stings in C. I know that they are special, but I always run into those allocation problems...

    I played a lot around with the plugins on the weekend and now I think I got a good overview of what I need and what I can adapt for my one. It would be great to hear your profound judgement...

    The parts I need for steering a hue are:
    1. UPNP just for the discovery,
    2. HTTP-Requests and -Responses for steering the lights,
    3. in some time in the future a sound stream analyzer and maybe transcoder
    What I do not need: a server sending a stream to the hue.

    Matching that to your plugins I think the squeeze2cast covers most parts:
    1. It discovers the chromecast via mDNS (changeable, to be taken from squeeze2upnp),
    2. Steers the chromecast via HTTP-Requests and -Responses (needed),
    3. Does fancy stream stuff (needed in parts, to be taken from squeeze2roap).

    Is that correct?

    If yes:
    I can leave out the webserver.c, the upnp webserer & the upnp virtualdirs. Theses seem to simply send the sound stream.

    The HTTP-Requests for interacting with the cast are send in a chromecast stream, the socketID is stored as a attribute of the player (somewhere in the files concerned with castcore.c).
    The Responses seem to be handled in the squeeze2cast.c via GetTimedEvent.

    I am asking to identify where the requests are sent and where the responses are processed. Once I have that I think I can start the show.

    A more sideshow question: Is there a bridge similar to shairtunes that exposes LMS as a chromecast for streaming with android sound to it. Usage would be: hit the chromecast button in an app, select the lms-chromecast & enjoy.

    I would then use the routines in squeeze2cast together with jansson as this seems to be quite lightweight...
    I need to think about all that. If you want to be most future proof, starting from squeeze2raop is the best base as it includes audio decoders, but it's the most difficult base to start with as it does not have any UPnP capabilities included ...

    Let me propose that: I can try to, if you want to, build a framework based on squeeze2raop during next weekend that would provide you a squeeze2raop-based structure but with UPnP detection and all airplay specificities excluded. If it's not too long, it might be done during the weekend. Then You'd have to put all the hue specificities
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  7. #17
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    227
    Quote Originally Posted by philippe_44 View Post
    Let me propose that: I can try to, if you want to, build a framework based on squeeze2raop during next weekend that would provide you a squeeze2raop-based structure but with UPnP detection and all airplay specificities excluded. If it's not too long, it might be done during the weekend. Then You'd have to put all the hue specificities
    Well, being honest, that would be really awesome. Not only for my specific project, but also for future bridges.
    I would use this framework for setting up the bridge from plain "empty" files using this framework hoping to get all var-names etc. in a clear description and using only the function etc. that are really necessary to keep the code simple...

    If I could provide you with some info front up or more detailed info let me know.

    What I would do then is to work with that framework implementing the steering stuff for the hue (e.g. communication etc.). Once I got that in a plain manner I think there will be again sime harder time getting the place in the code where to hook in for the PCM analysis for getting the values for setting the lamps. But that is for the future.

    Here the state of the project on my side to give you an impression and some background info. I thin that always help for not being too abstract...

    So far I got the following working:

    • DISCOVERING THE HUE BRIDGE:
      For discovering the hue on the network there is simply a UPNP search done via SSDP (https://www.developers.meethue.com/d...ge-discovery): "Best practice there is to wait 5 seconds for receiving all discovery responses before goin forward. If the responses contain “IpBridge”, it is considered to be a Hue bridge, and additional information can be retrieved." That's something I got (up to now partly) working, but it seems very blown up in the code due to the fact that the hue does not need everything in the UPNP code of squeeze2upnp.
      Background info: There are usually 3 methods available for discovering a hue bridge where UPNP is the best choice. The others involve an internet portal or use direct check with the known IP adress. (also mentioned in the link).

    • COMMUNICATION WITH THE SYSTEM:
      Therefore, http-request of different kinds are used (GET, PUT, POST, DELETE) containing JSON objects in the body and directly getting responses from the hue system by receiving JSON objects. For this communication a registration has to be done when first connecting to the hue system.

    • EXAMPLE COMMUNICATING. CONNECTING TO THE HUE:
      Once a new hue system is discovered there has to be done an authentication. Here the url "http://<ipAdressOfSystem>/api" is called with a "POST"-request. The body of that request contains some pattern like
      Code:
      {"devicetype": "my_hue_app#iphone peter"}
      in JSON format. The bridge will respond with a JSON statement a username.
      Code:
      [{"success":{"username": "83b7780291a6ceffbe0bd049104df"}}]
      That is something I also got working. Here I have to think of something special: User interaction for getting the username (the button on the device has to be pushed). But okay, that's cosmetics...



    NEXT STEP ON MY TASKLIST:
    Do some functions and structures for the commands and steering of the hue.


    The full api is documented here if you are interested: https://www.developers.meethue.com/philips-hue-api
    Last edited by chincheta0815; 2017-04-19 at 01:20.

  8. #18
    Senior Member
    Join Date
    Jan 2011
    Location
    Germany
    Posts
    227
    A question concerning "squeezetiny": Is it easily possible to update that to the latest "squeezelite" source?
    I saw that squeezelite contains a output_vis.c for visualizing...

    As the squeezetiny files seem to be mostly coming from squeezelite I thought about updating the file in squeezetiny and using the output_vis.c for the sound signal analysis and steering of the lights.

  9. #19
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,204
    Quote Originally Posted by chincheta0815 View Post
    A question concerning "squeezetiny": Is it easily possible to update that to the latest "squeezelite" source?
    I saw that squeezelite contains a output_vis.c for visualizing...

    As the squeezetiny files seem to be mostly coming from squeezelite I thought about updating the file in squeezetiny and using the output_vis.c for the sound signal analysis and steering of the lights.
    I'll do that special version during the weekend then. It will do the LMS interface, UPnP discovery and threading, but all the rest will be empty. The squeezetiny piece is based on a more recent squeezelite version, although it's not the latest and the visualisation piece is not included, but you can probably bring it back.
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

  10. #20
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    3,204
    Quote Originally Posted by chincheta0815 View Post
    A question concerning "squeezetiny": Is it easily possible to update that to the latest "squeezelite" source?
    I saw that squeezelite contains a output_vis.c for visualizing...

    As the squeezetiny files seem to be mostly coming from squeezelite I thought about updating the file in squeezetiny and using the output_vis.c for the sound signal analysis and steering of the lights.
    one other thing: do you plan to have a virtual player for the whole hue bridge or per lamp?
    LMS 7.7, 7.8 and 7.9 - 5xRadio, 3xBoom, 4xDuet, 1xTouch, 1 SB2. Sonos PLAY:3, PLAY:5, Marantz NR1603, JBL OnBeat, XBoxOne, XBMC, Foobar2000, ShairPortW, JRiver 21, 2xChromecast Audio, Chromecast v1 and v2, , Pi B3, B2, Pi B+, 2xPi A+, Odroid-C1, Odroid-C2, Cubie2, Yamaha WX-010, AppleTV 4, Airport Express

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •