Speak EV - Electric Car Forums banner

1 - 8 of 8 Posts

·
Registered
Joined
·
29 Posts
Discussion Starter · #1 ·
Had our meter upgraded to smets2 smart a few months ago on Octopus go. Took a few weeks to get up and running but all looked to be working.

until this morning - The IHD is flashing the signal bar and rebooting itself every minute or so.

Anyone had this before and is there an easy fix? The IHD is less than 5m away from the gas and electric mains boards/actual smart meters.
 

·
Registered
MG EZS 2020
Joined
·
4,921 Posts
Had our meter upgraded to smets2 smart a few months ago on Octopus go. Took a few weeks to get up and running but all looked to be working.

until this morning - The IHD is flashing the signal bar and rebooting itself every minute or so.

Anyone had this before and is there an easy fix? The IHD is less than 5m away from the gas and electric mains boards/actual smart meters.
Have you tried powering it down for a few minutes and then power up again?
 

·
Registered
Joined
·
29 Posts
Discussion Starter · #3 ·
Have you tried powering it down for a few minutes and then power up again?
Yeah, you can hold the power button to restart it but not power it down (built in battery which you can’t access). It’s power cycling itself every minute anyway.
 

·
Registered
Joined
·
1,256 Posts
I had this a couple of months ago. Tried everything and eventually rang Octopus who booked in an engineer visit.

A couple of days before the engineer was due we had a short power cut. When the power came back on the IHD started working again .

I'm guessing it was actually the comms module in the meter that needed a reboot, not the IHD.
 

·
Registered
Joined
·
1,201 Posts
Yeah, you can hold the power button to restart it but not power it down (built in battery which you can’t access). It’s power cycling itself every minute anyway.
If it’s like ours, the battery only lasts a hour or two. If you leave it unplugged overnight, it should run down and then power off completely. Maybe a reboot will then sort it?
 

·
Registered
MG EZS 2020
Joined
·
4,921 Posts
Yeah, you can hold the power button to restart it but not power it down (built in battery which you can’t access). It’s power cycling itself every minute anyway.
Oh, different from mine. Mine's plugged into a usb port. Pull the usb out and the IHD switches off.
 

·
Registered
Joined
·
29 Posts
Discussion Starter · #7 ·
I had this a couple of months ago. Tried everything and eventually rang Octopus who booked in an engineer visit.

A couple of days before the engineer was due we had a short power cut. When the power came back on the IHD started working again .

I'm guessing it was actually the comms module in the meter that needed a reboot, not the IHD.
Interesting! I wonder if I could reset the meters by pulling the mains switch (don’t believe they’re wired into the fuse board?) Will try that thank you.
 

·
Registered
Joined
·
2,322 Posts
Someone on another forum who works in the sector posted this in the past few days:

Quote:

Bit of background information that may aid your understanding
  • There is only one HAN network, controlled by the coordinator, this also stores most of the keys as you say. The HAN has to be opened for joining for the initial network commissioning. This joining window is only open for a short while (for security reasons), maybe 5 minutes, or an hour, or even 24 hours. If the joining window is not open no new devices can join the HAN.
  • The keys are stored in non-volatile memory in each device, so if a device loses power it can “re-join” the network without the joining window being opened. However, if you reset a device, say restore to factory settings, then the keys are erased and the device can no longer join the HAN except by a repeat of the commissioning step.
  • Generally, the ESME does not push data to the IHD, the IHD polls the ESME for the data it needs. Similarly for the GSME, but because the GSME is mostly asleep, the IHD has to poll the gas proxy on the CH.
  • There is a keep-alive cluster in each device. The ESME polls the keep-alive in the CH to check that it is still there (so a heartbeat function) on a regular basis. If the ESME sees a number of consecutive fails of this heartbeat, it assumes the CH has failed/is being replaced, so it enters a TCSO (Trust Centre Swap Out) process. It scans all the Zigbee channels looking for the replacement CH. If it fails to find a new CH, then it goes back to look for the original CH.
  • The HAN interface between CH and ESME is quite narrow, there are only a few Zigbee Clusters involved
  1. Time Cluster. The HANs sense of time
  2. Keep-Alive Cluster. As explained above
  3. OTA Cluster. For firmware upgrades
  4. Tunnel Cluster. This is a way for non-Zigbee protocol messages to be transported across a Zigbee network. Most of the CH<->ESME comms passes over this channel. The GBCS messages generated by Service Requests from the head end are sent this way. They are usually encrypted so that only the ESME and the source of the message can decode them. Note that this is not the Zigbee Network/Application level encryption, but yet another level of encryption.
  • In contrast, the ESME<->IHD interface is quite wide, it uses many of the Zigbee Clusters
Most Zigbee Clusters are just “there” if instantiated in the product. The Tunnel is slightly different. The Tunnel Cluster can support a few tunnels, so there is an initial negotiation phase to establish which tunnel to use. In the CH<->ESME case it is the CH that initiates this process. So if the tunnel gets reset for some reason and the CH has no heartbeat on tunnel operation, then the ESME wil go deaf from the head ends’ point of view, but will quite happily keep talking to the IHD.

And:

There is only one HAN, and all devices communicate on that. There are CH<->ESME, CH<->IHD, CH<->GSME, ESME<->IHD communication paths (using Zigbee Clusters) on that network. The network is a CSMA-CA (Carrier Sense Multiple Access - Collision Avoidance) network, so every device can (potentially) talk to every other device but only one device can talk on the network at a given time. At the test centres there are hundreds of HAN networks active at the same time happily working so the CA bit seems to work. What probably doesn’t happen at the test centres is leaving a given HAN up for weeks on end as in a real installation.

If a previously functioning network stops working then some possibilities are
  • A new significant source of RF interference has appeared and is wiping out all HAN communications
  • The CH has had a brainstorm and told all devices to leave the HAN.
  • Tunnels have failed and the CH has not restored them.
  • RF reception is marginal (either due to range or building construction) so the devices on the HAN have fallen into TCSO hell.
  • A new intermittent source of RF interference has appeared and driven the HAN into TCSO hell.
  • Firmware bugs and design flaws.

Unquote

(credit: Alun)
 
1 - 8 of 8 Posts
Top