New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Two Interfaces attached to iobroker/Raspi: SMA-EM listen on wrong Interface #403
Comments
The adapter binds to all interfaces which have a valid IPv4 address when the adapter is started. Can you confirm that the wlan0 device has a valid IPv4 address? |
@Flippo710 |
@Flippo710 |
@Flippo710 |
No, I didnt configure direct meter communication...(well, I didn't read anything about it, or that I have to configure it...) And I get no packages from this MC :( |
@Flippo710 |
@Flippo710 |
I have actually the same problem when I assign multiple IPs to one NIC. The last version working for me is 0.6.1-beta.0. I still have this version in production. It would be helpful to be able to choose which IP to use. |
@krafel |
@pdbjjens here I have teh same Issue. The log of the start of sma-em is like the following Hope you could help me out and get the sma-em adapter running. Many thanks and kindest regards |
@Rennsemme5 |
@Rennsemme5 |
Yes, the SMA components are within the same network as the RasPi. all components are connected with LAN. The switch is the one which is proposed from SMA. It is the TP-Link TL-SF1005D. |
@Rennsemme5 |
I don't need WLAN on RasPi. You think I should turn it off directly at the raspi direct metering is configurated. Hope that helps a little bit |
@Rennsemme5 |
yes, direct meter communication was the reason. I deaktivated it and now it looks great. So I have to follow up, if there are problems on the SMA products without direct comunication. Hopefully not. Many thanks for your help. |
Describe the bug
I have to networks attached to Raspi and iobroker. My Solar SHM is attached to wlan0 instead of eth0. The adapter listens to eth0 instead of wlan0. So i can't reach my SHM.
To Reproduce
Steps to reproduce the behavior:
Listen via UDP on Device eth0 with IP XXX.XXX.XXX.XXX on Port 9522 for Multicast IP 239.12.255.254
Versions:
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: