My setup is as follows:
Home assistant running on a VM server with CC2531 zigbee2mqtt USB stick.
Next to server there is a Philips Hue hub.
I have a number of Hue lights and switches connected to Philips Hue hub. This is integrated using Philips Hue integration to Home Assistant.
I have some Aqara sensors I'm connecting to Home Assistant via USB stick. And integrated using MQTT into home assistant.
Lights/switches work throughout the house - mesh is working correctly. Some devices are pretty far away.
Aqara sensors ( they are all end devices ) are not working too far from USB stick.
This leads me to believe that at this point i have two separate zibgee meshes - one native philips hue and one for aqara.
How can i merge those two meshes ? I guess I'd have to do away with philips hue bridge and merge all philips devices into mqtt mesh ? Is there another way ?
Thanks,
B
You can either decide to use only your Z2M mesh and discard Hue. That needs to pair all devices from the Hue bridge to the CC2531 and Z2M. Keep in mind that CC2531 has limited resources and you can encounter issues if you have too many devices.
What I suggest is to keep two distinct networks but move some of the bulbs to the Z2M mesh in order to use them as relays, especially for your furthest Aqara end devices.
Related
I want to know if it's possible to use a BLE module for both mesh networking and point-to-point connections at the same time.
Rationale:
The embedded linux (EL) product that I am designing needs to be able to connect to BLE peripherals like a heart rate monitor (sports grade, not medical) and the product needs to communicate with others of its kind.
I also need a very low power way of sending data from all EL devices to the internet. Ideally with only one of the products supplying a connection to the internet.
I am open to other solutions or reasons why this might not be a good approach even if it's possible.
Here is a rough block diagram of what I'm trying to achieve:
The block diagram does not show a HR connected to every EL device, however this would be a possibility as well.
Green = Embedded Linux Devices
Red = Heart Rate Monitors
Blue = An internet connection to the cloud
Yellow = connections between Embedded Devices
Option 1 - WiFi
The first option I considered was a wifi connection between the EL devices, however this will consume much more power than BLE.
Option 2 - BLE mesh
Using a BLE mesh seems like the best solution, if and only if, it's possible to do point-to-point connection at the same time.
Yes, this behaviour is specified in the BLE Mesh Profile specification in chapter 2.3.11. What you are looking for is a Proxy Node:
Proxy feature – the ability to receive and retransmit mesh messages between GATT and
advertising bearers.
Also take a look at the Ultimate Mesh Tutorial where they also describe the proxy node:
To allow communication with a mesh network from a non-mesh-supported BLE device, a special type of node called a proxy node can be utilized. A proxy node acts as an intermediary and utilizes GATT operations to allow other nodes outside of the mesh network to interface and interact with the network.
The protocol used in this case is called the proxy protocol, which is intended to be used with a connection-enabled device (using GATT).
This is of course hardware and software dependent. Not every hardware or software stack supports BLE mesh functionality.
The wikipedia article for Bluetooth mesh networking has a list of currently availible software stack supporting BLE mesh.
Just for reference the Sony Remote Camera API only works by using a 1:1 Wifi Connection
The Wifi signal strength of my Sony DSC-HX60V camera already drops after a few meters distance. But I want to be able to remotely control the camera over a range of 50 meter. There is no way that the onboard Wifi can achieve this range.
So now Iam looking for a solution to this problem. If it helps a local Wifi router exists that covers the whole range:
A normal Wifi repeater seems to be the best option, but according to a Forum Post using a repeater does not work, because the repeater acts a client and the camera can only connect to one client at the same time. Did someone got it to work with a repeater?
Additionaly I was thinking about using a Raspberry Pi with a second Wifi adapter that connect to the local Wifi and manages the API requests.
Any other ideas?
Disclaimer:
Even tho this Question may be more Hardware and Network related and thereby fits more into the SuperUser Network. A working Network connection does not necessary imply that the API is working aswell. This is why I posted this Question here
If you have a router which can work in 'client mode' that should be able to make a 1:1 connection with the camera, and then present that link over ethernet - you may have issues with network addresses and/or discovery if your main network is a different IP range to what the camera offers/DHCP's.
Some of the Sony cameras support 'multi-wifi' where the camera connects to an external device (normally the LiveViewRemote, but can be a router). Unfortunately the HX60 (and presumably any of the Play Memories SmartRemote app based ones) does not seem capable of this.... maybe the QX1 is an exception as it's supposed to work like this.
This connection connection is managed via WPS, and once connected the RemoteAPI works well. Works for my AS100.
If you are looking to set up a RaspPi, I can confirm that it works with this Python library:
https://github.com/Bloodevil/sony_camera_api
https://www.youtube.com/watch?v=xR3gAfu4Hfw
I have seen multiple links about controlling philips hue lights uisng Amazon Echo. I wanted to know if we can do the same with self built alexa made using RaspberryPi instead of real amazon echo ?
Is there any difference between both ?
Regards
Kalyan
Absolutely. As long as you have set up the RasberryPi to ask as an Alexa enabled device, all you have to do is connect it to your account, go to the Alexa phone app and discover your lights. Then it should work. It will also have all of the other functionality that Alexa has since all the RasberryPi is is a microphone and speaker and Alexa's logic is in the cloud.
Guides for this:
https://github.com/alexa/alexa-avs-sample-app/wiki/Raspberry-Pi
https://pimylifeup.com/raspberry-pi-alexa/
You should try DIYhue on GitHub for all these functions. It contains direct Alexa and Philips Hue implementation.
Can Zigbee/XBee Routers automatically associate with a Zigbee Coordinator, without having to manually configure PAN, DH and DL of the coordinator?
In my setup, I have a XBee Coordinator API and several XBee Router AT, and it appears that I need to setup the Router AT units manually.
In a commercial Zigbee product, how do you avoid this manual programming of the Zigbee units? For example, how does the single Philip Hue bulbs that you purchase knows which Bridge to associate with?
As far as the Philips Hue bulb, perhaps you can find information on commissioning at the Philips Hue support site.
XBee networks are simpler. You can configure the PAN ID of the routers to 0, and they will attempt to join any network they see. If you set DH/DL to 0 as well, they'll use the coordinator as their default destination. If you configure the XBee with security (look at EE (encryption enable), EO (encryption options) and KY (shared link key)), the coordinators and routers will only join each other. The routers won't join another XBee network, and the coordinators won't let any devices without the correct key join.
My application will be having many microcontrollers with sensors monitoring a large area. The application requires all these microcontrollers to send the data to the master microcontroller. From the master microcontroller the data must go to desktop PC via serial connection and to a mobile application. Which one (Zigbee/GSM) will be suitable?
This completely depends on what you mean by "Wide Area." A few hundred square meters? A few hundred square kilometers? Zigbee is more cost effective and simpler to implement if you're within range. You could even mesh your nodes together to extend the collective reach of your network. Otherwise, well, you have no choice but to use something like GSM.
RF Line-of-sight range on readily available XBee Modules can be up to 2 miles. Higher power models can be had with 40 mile LOS range.
If you are within range, I would recommend ZigBee as that saves you the cost from having a sim-card in each device.
Buy zigbee modules that have SDK and HW ability for mesh networking. That will give you ability to talk to far nodes via routing nodes. Unfortunately zigbee can not do adhoc mesh networking so you need to know in advance what your routers will be, or to program your nodes routing your self. Another 802.15.4 module (by Synapse) can solve all this since it supports ad hoc mesh networking for you via SNAP protocol. It is not zigbee compatible, but Synapse modules are already adopted by big players like Garmin so this should not bother you. They also run much longer on batteries then zigbee modules. They can also give onboard analog and digital IO accessible without need for additional MCU (although you can connect it and give control to it if you wish). There is also USB stick that will enable your PC to talk to these modules.