I’m trying to create a device handler for some multiple-switch wall plates that use Tasmota firmware.
It’s actually working fine for the 1st device I added, but the second one is not receiving the HTTP responses.
I can see logs for the the command going out of the hub, and logs in the physical device of the message being received, but the response just never gets back to the hub.
The handler has configuration parameters for IP, port, MAC , switch number.The device network id is set in a “MAC-SWITCH” format, which are unique and in theory should work (and it does work for the 1st device).
Any ideas on what the problem may be? I just went through it a lot of times and idk if I’m missing something.
Edit: To clarify, one 1-switch device is working as expected, a second 2-switch device (with its own IP, MAC, DNI) with 1 switch configured does receive requests from the hub, but responses do not appear in hub logs.
Self update: setting the device network id to the MAC makes the other switch receive messages, still can’t figure out why “mac-id” works only for the 1st switch
Still does not solve my problem since each device needs a unique DNI, and i need different DNId for switches on the same device(mac address.
Both switches have the same Mac address. You won’t be able to use the same MAC for two devices. What you have to do is create a parent device with 2 children…one for each switch. You parse the message to the correct device in the parent.
Take a look at ST_Anything. It uses a similar model.
Im using a different MAC address for each physical device, and the idea was to use a DNI in the format “mac-switch#” for each switch in the same device.
I thought of parent-child but this way I get a different button in th ST UI for each switch in the same wall plate. I also tried the parent device route but got stuck at the device not showing any tiles lol.
It will work for one of the two devices. But it will never work for them both. Because two devices can’t have the same network ID in ST. and the Network ID has to be the MAC address for the parse method to be used correctly.
It may work on the request side, because you just make the request, it knows which device to return it to. But it’s not going to work 100% of the time. Also, you won’t be able to receive unsolicited messages. If you are looking at using a multi-gang wall-plate, I assume you are going to have local changes on that device that you want reflected in ST as well, correct? Well, the only way to get unsolicited HTTP messages to be parsed correctly in ST is to send them as POST messages and send them on port 39500. If your wall-plate sends those messages to ST on that port, then it will automatically be passed off to the device with a Network ID that matches the MAC address in the header. That’s how many wifi integrations handle the unsolicited messages to the Hub. You just have to send those messages to the Hub’s local IP.
There is a DNI parameter for hubAction, which I assumed is the device id that the response of this call would get back to. So it is an undocumented “feature” that it MUST be the exact mac?
My thought process was:
set up a ST device for each gang in one switch. Network id would be in the format “mac-gangnumber”
send this id in the dni hubAction parameter, so responses would come to this device
Parse the gang # and act accordingly
This is actually working for just ONE physical device (the ST device has a “mac-1” network id). Its DNI is not the device’s mac but “AABBCCDDEEFF-1”, and it works anyway.
But doing the same for other physical devices (with ids as “secondmac-1”, “thirdmac-1”) mostly does not work (it did for a while). This is not even the “second gang of one switch” stage yet, just “first gang of second switch”; and this is what baffles me
Guess I’ll keep working on the composite device at the same time and figure out parent-child tiling.
Sorry for keeping asking questions, but my engineering mind needs to know the 'why’s