ioBroker.chromecast
ioBroker.chromecast copied to clipboard
iobroker-community-adapters
Google Home Mini in different subnet does not work any more
Contact Details
No response
What happened?
I used version 2.3.1 for quite some time successfully. Now I updated to the newest version 3.1.0 and it does not work any more.
Situation:
- iobroker is installed on a Raspberry Pi in subnet 3 (192.168.3.XXX)
- 3 Google Home Minis are separated in subnet 66 (192.168.66.YYY)
Error message is that the adapter cannot get MAC addresses for the devices (see log below). I assume, the problem there is the breaking change in 3.0.3 from jey cee that object IDs are now mac addresses instead of names. As MAC addresses are only available for devices located in the same subnet in the ARP-table, there is no way for the adapter to figure out the MAC addresses of the devices.
As I entered the IP addresses in the configuration and (at least until version 2.3.1) this worked, I assume it is sufficient to contact the devices via their IP addresses. Why is the MAC address required/used for the object IDs? The "old" object IDs also have been very stable against hardware changes. Id one Google Home Mini was broken, another one could be configured and used and the object id names did not change, so no need to update e.g. scripts.
Can I use the newer versions of this adapter anyhow? Moving the Google Home Minis in the subnet 3 is not an option for me...
Adapter Version
3.1.0
JS-Controller Version
4.0.24
Node JS Version
v16.18.1
NPM Version
8.19.2
Operating System
Ubuntu
Relevant log output
chromecast.0
2023-01-22 11:08:47.855 error Google_Home_Wohnzimmer - Error: The id is empty! Please provide a valid id.
chromecast.0
2023-01-22 11:08:47.807 error Google_Home_Wohnzimmer - Cannot get MAC for "192.168.66.107": TypeError: Cannot read properties of undefined (reading 'replaceAll')
chromecast.0
2023-01-22 11:08:47.805 error Google_Home_Eingang - Error: The id is empty! Please provide a valid id.
chromecast.0
2023-01-22 11:08:47.803 error Google_Home_Kinderzimmer_Anna - Error: The id is empty! Please provide a valid id.
chromecast.0
2023-01-22 11:08:47.796 error Google_Home_Eingang - Cannot get MAC for "192.168.66.111": TypeError: Cannot read properties of undefined (reading 'replaceAll')
chromecast.0
2023-01-22 11:08:47.788 error Google_Home_Kinderzimmer_Anna - Cannot get MAC for "192.168.66.109": TypeError: Cannot read properties of undefined (reading 'replaceAll')
Anything else?
No response
Anyone else having this problem?
@Jey-Cee The comment for version 3.0.3 is from you, thus I assume, you implemented that: " Breaking change: Object IDs are now mac addresses instead names" -- Can you explain why you did change it this way?
This is because a id should be everytime the same as the device was deleted/disconnected/removed and new added.
Good point, @Jey-Cee. Can MAC adresses be used as IDs, but still the IP-addresses used to communicate with the devices? My Google Home Minis are separated in subnet 66 (192.168.66.YYY) and, thus, I have errors in the logs and cannot use the new version.
A proposal for a solution:
- In the instance settings for chromecast-adapter, tab "DEVICES", there is a hint: "The adapter will try to detect Google Home adapters in the same subnetwork using mDNS but you can also manually add here devices bellow."
- As my devices are in a different subnetwork, I added them manually (name, IP, port, type).
- What is missing is a way to enter the MAC address manually. This is required as resolving an IP address to MAC is not possible when the devices are located in a different subnet.
- If you provide the possibility to enter MAC addresses in the "DEVICES" tab and check there for a MAC address before using getMAC to resolve IP to MAC, it should be possible to stay with MAC addresses as IDs, but allow to isolate devices in a different subnet.
Would that be a possible mitigation for the problem?
@Jey-Cee: Is it possible to enter the MAC address manually and additionally the IP address in case the devices are in different subnets? See proposal above...
Please note: Will only work if you manually configured your Chromecast devices in the adapter configuration page as your chromecast devices are located in a different subnet and, thus, cannot be found automatically.
If you have this problem as well, I have figured out a work around:
On your iobroker server, open /opt/iobroker/node_modules/iobroker.chromecast/lib/chromecastDevice.js with an editor, e.g. nano.
Search for the use of getMac (not the definition at the beginning of the file!) and adapt the code as shown here:
try {
// original code:
// this.id = await getMac(this._connection.host);
// this.id = this.id.replaceAll(':', '');
// Work around: use the names defined in the configuration instead of MAC address as identifier for your devices
this.id = this._connection.name.replace(/[.\s]+/g, '_');
} catch (e) {
adapter.log.error(`${this._name} - Cannot get MAC for "${this._connection.host}": ${e.toString()}`);
}
Save the changes, restart the Chromecast-instance in iobroker and it should work again, NB: It is a good idea to delete the chromecast objects/states that have been created by older versions as there have been quite some changes. The new objects/states are automatically generated when the instances are restarted. There might be some script errors coming up as several states are now hanging in a different path and, thus, your scripts might read/write non-exitsting states.
Hope it helps some of you to update to the new version of the adapter.
Search for the use of
getMac(not the definition at the beginning of the file!) and adapt the code as shown here:
You really should catch the 'Cannot get MAC' case and only in that scenario use a different ID. TBH, I would consider putting these devices in a different object tree (under 'Remote devices') or something because they most likely aren't going to play nicely as seems Chromecast relies on all devices being on the same subnet... and because of that, I am reluctant to encourage users to do that by making such a code update.
There is probably a better solution... I can understand why you'd want to put Chromecasts and other devices in a different subnet, but why isn't your Pi also in that other network (multi-homed)? FWIW, I have a few machines running IoB. I have a subnet that our 'not trusted' A/V gear that is on. I give the IoB hosts multiple IP addresses in both an 'Automation' subnet and the 'A/V' subnet so they can see everything necessary. Why do you not want to do this?
@raintonr You are completely right, I will re-do the patch on the weekend and see, if I can create a solution that can be used in a more general way that is compatible with both use cases: devices in a different subnet and devices in the same subnet. I was so happy to find that this workaround worked that I did not take the time to make it properly.
A different object tree is not required. I integrated only the change described above and without any further modification, all manually configured chromecast devices work like a charm. Directly and also with sayit. Only the auto-discovery does not work cross-subnet.
I do not want to put chromecast devices and my iobroker in the same subnet because if there is an security issue with the chromecast devices, lateral movement to the iobroker would be possible.
I do not want to put chromecast devices and my iobroker in the same subnet because if there is an security issue with the chromecast devices, lateral movement to the iobroker would be possible.
IMHO, with correct configuration of the firewall between Chromecasts & IoB (& IoB host networking) there really shouldn't be a problem. I prefer that over a different subnet approach and would avoid the need for any changes to this adapter.
As far as I know, there is no network-based firewalling taking place between devices on one subnet, traffic between these devices might not even reach the network-based firewall. Thus, a host-based firewall on IoB would be required. This is a possible way, but I prefer the way I have it right now and avoid the need to maintain multiple firewalls (network based and host-based). And this worked without a problem until version 2.3.1, when devices have been added manually in the configuration.
Then Jay-Cee decided to move away from names as IDs to MAC addresses to keep them stable even when a device was deleted/disconnected/removed and newly added, which is a highly desirable property for IDs. What was forgotten back then is, that getMac is only working on the same subnet (ARP packets are limited to the local segment as they are not routed). Now, manually added devices that are not located in the same subnet are not working for the only reason that getMac is not delivering the MAC address. For no other reason, especially no chromecast-protocol related issues. Only exception is the discovery protocol: Here mDNS/DNS-SD is used and this is only working in the subnet where the discovery-request originated as these protocol is not routed. During regular connection, devices are using IP-based protocols. To overcome the restrictions of the discovery protocol, the manual configuration of devices was added to the adapter, see the comment in the Devices-tab of the configuration: "The adapter will try to detect Google Home adapters in the same subnetwork using mDNS but you can also manually add here devices bellow."
In this manual configuration, the name of a device can be defined when you add a device manually to the configuration (you can even specify the MAC address here if you want to make the manually added devices look identical to automatically detected devices in the subnet of IoB). Thus, my reasoning is, that for manually added devices, the used already defined the ID (can be a name, can be the MAC address or whatever the user decided) and this ID is stable as long as the IP address of the device is stable. Thus, this name should be used.
My proposal for a clean solution is therefore:
- Automatically detected devices: getMAC is used to determine the MAC address and this is used as ID for the device. This works always as the used discovery protocol is limited to the local subnet anyway and, thus, getMAC will always be able to retrieve the MAC address (as long as the device is switched on and can respond at the time the adapter is started)
- Devices that are added manually to the configuration are using the ID defined there and getMAC is not used at all for these devices.
I think that is a clean solution, honoring the wish of Jay-Cee for stable IDs, but also honoring the initial reason to provide the devices tab in the configuration to manually add devices that are located in a different subnet. Thus, this solution would fix a bug that was introduced with the braking change using MAC addresses instead of names as IDs.
