Update to latest version issues

[Anjerlaan]

Hi,

I am using your cast node for a while now, but I have not updated it to the last version yet. If I do that will it affect my flows? All my payloads start with:

payload: {
type: “TYPE”,

}

Do I have to add the “app” type row or can I leave it blank? All my current flows use the defaultMediaReceiver

payload: {
app: "DefaultMediaReceiver",
type: “TYPE”,

}

[i8beef]

Nope, its optional and defaults to that: https://github.com/i8beef/node-red-contrib-castv2/blob/master/castv2-sender.js#L638

What you WILL have to do is define your connections if you haven't upgraded in a while. The node now maintains a constant connection to all configured Cast devices, sort of the same model as your phones, Chrome browsers, etc. on the local network (i.e., this is closer to Google spec now).

[Anjerlaan]

Okay....Do you maybe have an example of how to define the connection?

[i8beef]

You define a connection just like you would in an MQTT node, etc. Just open it, and the first field is where you select / edit the connection.

Once you get into defining a connection, there are two options: specify the static IP / port (usually 8009) of the cast target, OR you can push the search button to attempt to do mDNS discovery for them (see docs if you're using docker, mDNS doesn't automatically traverse the network there).

I recommend using static IPs if you can, but the mDNS discovery should work fine as well, its just the static IP is more "stable".

[Anjerlaan]

Hi,

I just updated to the latest version. All flows are working now, but I have some other minor questions:

1. Under the "node-red-contrib-castv2" nodes I use in several flows I have seen the following statusus:

• Connected
• Connecting
• Disconnected
• Joined

What does Joined mean?

2. In the connection node I have left the field "Target" empty...what should I fill in there?

3. One of my speakers is a JBL wireless with Google Assistent integration. This Speaker is only used in the summer when we are sitting in the garden...but in the winter it is disconnected. In my "Doorbell" flow this speaker is also used...but since it is disconnected from the local network, Node-Red keeps trying to connect. Does this have effect on the memory usage of the Raspberry Pi Node-Red is running on?

[i8beef]

1. Yes the status changes according to connection status. "Joined" means there is an active application running on the chromecast which was supported, so it "joined" the session so it can control / get updates from it.
2. Host/port and Target are mutually exclusive. The Target is used for connecting to named instances that aren't directly addressable (Speaker groups). That search button next to it will attempt to scan the network for advertising Chromecast's. You can actually address ANY Chromecast by name with that, but Speaker groups are the only ones that are ONLY addressable that way. It also requires your node-red instance is on the same network as the Chromecasts to work with the mDNS advertisement (see docs).
3. It SHOULDN'T, but if you see any issues, let me know. Reconnects are done with JS timers which are notorious for leaking if not cleaned up correctly.

[Anjerlaan]

3. It SHOULDN'T, but if you see any issues, let me know. Reconnects are done with JS timers which are notorious for leaking if not cleaned up correctly.

All my Function Nodes use the JS Timer function. I can't figure out a different way to turn up and set back the volume to default level. Here is an example of one function node in a flow "Send castv2 Deurbel Tuin"

var msgVolumeSet = {
  payload: {
    type: "VOLUME",
    volume: 60
  }
};

var msgMedia = {
  payload: {
    type: "MEDIA",
    media: {
      url: "http://192.168.1.51:1880/deurbel-aangebeld",
      contentType: "audio/mp3",
      streamType: "BUFFERED"
    }
  }
};

var msgVolumeBack = {
  payload: {
    type: "VOLUME",
    volume: 40
  }
};

var msgClose = {
  payload: {
    type: "CLOSE"
  }
};

if (msg.payload.idx == '50') {
    if (msg.payload.nvalue == '1') {

      node.send(msgVolumeSet);

      setTimeout(function(){
        node.send(msgMedia);
      }, 2000);

    }
    if (msg.payload.nvalue == '0') {

      node.send(msgClose);

      setTimeout(function(){
        node.send(msgVolumeBack);
      }, 1000);
    }
}

The total flow looks like this:

[i8beef]

Yeah that seems reasonable. Alternative could be to do it with a separate delay node so node-red handles the timers for you, less chance of anything weird happening due to node-red's asynchronous processing of nodes... You could even make that into a little subflow so it still looks like one node.

I don't know that there's anything wrong with what you are doing there though, I've just never done timers in node-red functions before so I don't know the caveats.