Problemen Unifi camerasysteem sinds ingebruikname NAS

[Kenar95]

Mijn vraag
Sinds twee weken doet mijn unifi camerasysteem raar. Voorheen nooit problemen gehad. Ongeveer 1x per uur verliezen de bedrade camera's tussen de 4 en 40 seconden hun verbinding. Dit is in de cameratijdlijn heel goed te zien. Is zowel bij mijn 2 Poe bedrade camera's als de wifi deurbel.
Terugkijkend is de dag dat de ellende begon waarschijnlijk de dag geweest dat ik mijn Synology NAS 220+ in gebruik genomen heb. Ik vermoed dat er iets met elkaar stoort, maar ik kan er niet achterkomen. De unifi protect en network app zijn soms ook niet of erg slecht te benaderen. Voorheen werkte alles soepel.

Kan het zijn dat mijn NAS stoort met de Unifi Cloudkey gen2+? Iets mogelijk met een firewall zag ik online ergens? Iemand enig idee wat er mis zou kunnen gaan en welke instelling ik moet wijzigen?

Mijn dank is bij voorbaat groot!

Relevante software en hardware die ik gebruik
-Unifi Cloudkeygen2 plus (incl. network en protect app)
-2x bullet G4 camera bedraad
-1x g4 doorbell
-1x synology nas 220+

[Speed24]

Dan zou ik sowieso de NAS een uur uit zetten, dan weet je 100% zeker dat het daar zit.

Hoe heb je de Synology geinstalleerd? Als die bijvoorbeeld ook DHCP-server is, kan dat eventueel storen met de DHCP-server van je router.

[Kenar95]

Speed24 schreef op zaterdag 8 juli 2023 @ 16:25:
Dan zou ik sowieso de NAS een uur uit zetten, dan weet je 100% zeker dat het daar zit.

Hoe heb je de Synology geinstalleerd? Als die bijvoorbeeld ook DHCP-server is, kan dat eventueel storen met de DHCP-server van je router.

Uitschakelen van de NAS is sowieso een hele goeie, suf dat ik daar niet aan gedacht heb. Staat nu uit.
Hoe bedoel je de nas geinstalleerd? Ik heb hem wel een eigen IP adres gegeven in de instellingen.

[Kenar95]

Update: met NAS uitgeschakeld doet het probleem zich alsnog weer voor. Enige wat ik terug kan halen is dat op de dag dat het begonnen is, ook onze slimme meter vervangen is (en de stroom er dus af is geweest). Mogelijk zit hier een oorzaak, hoewel ik de cloud key al een keer opnieuw opgestart heb.

[Kenar95]

Probleem opgelost!

Bleek dat er een Nest Protect op hetzelfde IP-adres als de Unifi Cloudkey gen2+ was gaan zitten. Protect eruit gegooid en cameraverbindingen worden niet meer onderbroken. Had dus niets met de NAS van doen.

@Speed24 bedankt voor je reactie.
En voor iedereen met verliezende verbindingen van je unifi camera's; even kijken of er niemand op hetzelfde ip adres als je Cloudkey is gaan zitten..

[Speed24]

Dat blijft toch wel raar.

Normaal gesproken is een DHCP-server in jouw netwerk verantwoordelijk voor het uitdelen van IP-adressen.
Die zorgt er ook voor dat er geen dubbele IP-adressen uitgedeeld worden.

Dan zijn er twee mogelijkheden:
- Een van de twee apparaten heb je op een vast IP-adres gezet (de Cloudkey? Of de Protect?) zonder dit IP-adres bij de DHCP-server te reserveren?
- Er zijn alsnog twee DHCP-servers in jouw netwerk?

[Kenar95]

Speed24 schreef op zondag 9 juli 2023 @ 10:33:
Dat blijft toch wel raar.

Normaal gesproken is een DHCP-server in jouw netwerk verantwoordelijk voor het uitdelen van IP-adressen.
Die zorgt er ook voor dat er geen dubbele IP-adressen uitgedeeld worden.

Dan zijn er twee mogelijkheden:
- Een van de twee apparaten heb je op een vast IP-adres gezet (de Cloudkey? Of de Protect?) zonder dit IP-adres bij de DHCP-server te reserveren?
- Er zijn alsnog twee DHCP-servers in jouw netwerk?

Ik heb inderdaad vaker het probleem dat er een nieuw apparaat op een in gebruik zijnd IP adres kruipt. Internet komt binnen via enexis router. Wifi staat daarop uit en zit met kabel door aan de Unifi Cloudkey welke met 3 APs het netwerk verzorgd. In de enexis router heb ik dhcp range van 110 tot 249, maar kijk daar verder niet naar om. In de Cloudkey kan ik alle verbonden apparaten ook zien en zien of het goed gaat. Soms gaat het dus mis. In unifi Cloudkey kan ik wel ip adressen toewijzen aan apparaten, maar die pakken ze nooit. Blijkbaar loopt dit toch via de enexis. Mogelijk moet ik in de enexis vaste ip adressen toe wijzen? Maar heb meer dan 80 apparaten aan de wifi hangen, en als ik een keer van provider wissel (en dus nieuwe router krijg) moet ik dit weer opnieuw doen?

[Ben(V)]

Het beste is enkel en alleen de dhcp server in je router te gebruiken en nooit een vast ip adres elders toe te kennen.

Als je er voor wilt zorgen dat devices altijd hetzelfde ipadres krijgen regel je dat in je dhcp server.
Daar kun je instellen dat een macadres altijd een bepaalt ipadres krijgt.
Op die manier krijg je nooit dubbele uitgegeven ipadressen en is alles op een plek geadministreerd.

En ja dat moet je opnieuw doen als je een andere router krijgt, maar hoe vaak is dat?
En even een spreadsheet van de macadressen bijhouden is een werkje van niets.
Dubbele ipadressen zijn vele malen vervelender zoals je gemerkt hebt

PS
Meer dan 80 ipadressen duid erop dat je iot devices over wifi gebruikt.
Dat is altijd een heel slecht idee en zal je wifi netwerk behoorlijk overbelasten door alleen beacons ervan.
Voor iot is wifi gewoon niet geschikt, gebruik daar zigbee voor die is daar voor ontworpen.

[ Voor 18% gewijzigd door Ben(V) op 09-07-2023 12:21 ]

[Kenar95]

Dan denk ik toch even wat tijd vrij te maken om inderdaad alles een vast IP te geven in de router.
Daarover een vraag: nu zie ik dat ik de DHCP server aan heb staan van .100 tot .254 en dat ik op basis van Mac adress static adress assignment kan doen.
Moet ik bijvoorbeeld de statische adressen toewijzen binnen .10 tot .99 en dan van .100 tot .254 vrij laten. M.a.w. moeten/kunnen je toegewezen adressen buiten de DHCP pool liggen, of moeten ze binnen de DHCP range liggen, maar zullen ze nooit meer dubbel bezet raken omdat ze toegewezen zijn?

Inderdaad schakelt alle verlichting in huis op Shelly, en die zitten op de wifi. Gelukkig geen performance problemen, heb in de shelly app alle apparaten een eigen IP adres kunnen geven, dus die veranderen niet steeds. En heb ook een enorm zigbee netwerk i.c.m. homey voor de nodige sensoren. De keuze voor shelly op wifi was kostengebaseerd, maar nog geen spijt van gehad gelukkig.